Verify the fork builds and tests green

Nobody has verified this fork builds. node_modules has never been installed in it, so the build and test suite have not been run once since the copy was made. Everything in #1 is theoretical until this is known.

There is a specific reason to expect trouble: package.json declares engines: ^16.20 || ^18.18 || >= 20.17, and the toolchain is from 2023 — yarn 3.5.0, karma, jest. Recent Node majors satisfy >= 20.17 nominally while being far newer than anything this was tested against.

Acceptance criteria

yarn install completes on a declared-supported Node version
yarn build completes
yarn test result recorded here — pass rate, and every failure listed rather than summarised
The Node version used is stated, along with whether the newest Node in the declared range works
If anything fails, a follow-up issue per failure

This gates everything else in #1. Until it passes, this is a source archive rather than a maintained build.

Context that changes what this issue is waiting on: CI could never have told us the answer.

Every workflow here was filtered to branches that do not exist on this fork, so yarn build and yarn test have not run in CI even once — full evidence in #16, fix in #17. This issue was written as though a green pipeline was merely unobserved. It was unobtainable.

Order of operations, now that the cause is known:

chore(repo): retire inherited Stoplight CI and org references #17 merges, which is what makes commit.yml fire on pull requests to main at all
A pull request touching packages/ runs it — paths-ignore skips .github/** and README.md, so a docs-only or workflow-only change will not do it. Every rule this build emits links to a 404 on Stoplight's docs site #20 is the natural first candidate
That run is the answer to this issue, across the 18.20.8 and 20.20.0 matrix the workflow already defines, on Linux and Windows, plus the browser job

The local check this issue asks for is still worth doing and is still unrun — node_modules has never been installed here. Worth noting for whoever picks it up: the toolchain is yarn 3.5 from 2023, current Node on the maintainer's machine is v25.2.1, and engines declares ^16.20 || ^18.18 || >= 20.17. v25 satisfies >= 20.17 nominally while being two majors past anything this was tested against, which is exactly the trouble this issue predicted.

The acceptance criteria stand unchanged. This comment only corrects what was blocking them.

The build works. First evidence in this repository's history, and most of the acceptance criteria are now answerable.

Once #16 landed and CI could run at all, Dependabot's pull requests were the first to exercise it — and they get past the install step, because Dependabot regenerates the lockfile as part of its own change. (Everything else fails first on the lockfile drift in #28; that is a separate defect and not a statement about this codebase.)

Results from run 30834789991:

Job	Result
`test-node (20.20.0)`	green, 2m17s
`test-browser`	green, 3m6s
`test-node (18.20.8)`	install ✓ · build ✓ · node tests ✓ · `Test harness` ✗
`lint`	install ✓ · build ✓ · commit lint ✓ · eslint ✓ · prettier ✗
`test-windows`	skipped, 0s

yarn install completes, yarn build completes, and the Jest and Karma suites pass on Node 18.20.8, Node 20.20.0 and in headless Chrome. The 2023 toolchain — yarn 3.5, karma, jest — works as-is on the Node versions engines declares. That was the specific thing this issue expected trouble from, and it did not materialize.

Acceptance criteria

yarn install completes on a declared-supported Node version — 18.20.8 and 20.20.0
yarn build completes
yarn test result recorded — Jest and Karma pass on both Node versions and in the browser
Node version stated — the matrix is 18.20.8 and 20.20.0, both inside ^16.20 || ^18.18 || >= 20.17
Whether the newest Node in the declared range works — still unknown. >= 20.17 is open-ended and the matrix stops at 20.20.0. Node 22, 24 and 25 are untested, and locally Node 25 cannot even run the repo's commit-message linter. This is the open half of this issue.
A follow-up issue per failure — below

The three failures, none of which are the test suite

Test harness — fatal: detected dubious ownership in repository at '/__w/spotlight-tools/spotlight-tools'. The composite action runs git rev-parse without the safe.directory exception that commit.yml applies in the job above it. Environmental, not a code failure. Own issue.
lint / prettier — README.md was edited during the rename without being run through prettier. Fixed in fix(repo): unblock CI, and correct the contact address in every manifest #28.
test-windows skipped in 0s — needs its own look. A silently skipped platform job is the kind of thing that reads as passing.

What this issue was actually waiting on

This was written as though a green build were merely unobserved. #16 showed it was unobtainable — no workflow could fire. Now that they can, the answer is better than the issue's own framing expected: this is a working build, not a source archive.

What is left is narrower and worth keeping open for: whether it builds on current Node, and why Windows silently skips.

fix(repo): make the CI that runs actually do what it claims

fix(repo): unblock CI, and correct the contact address in every manif…

fix(repo): make the CI that runs actually do what it claims (#30)

fix(rulesets): point rule documentation at docs that exist (#27)

fix(repo): make the CI that runs actually do what it claims (#30) (#31)

feat(repo): watch upstream and file each change as an issue, nothing …

Windows has now run, and my earlier comment on this issue needs correcting on two points.

That comment recorded test-windows as "skipped in 0s — needs its own look" and left the newest-supported-Node question open. Windows was turned on in #29/#31, and the post-merge run 30840176411 on main is the first result in this fork's history.

Windows: the tests pass

The failure in that job is not the test suite. Jest runs and passes on Windows — the log shows the suites executing:

PASS @stoplight/spectral-rulesets .../arazzoStepFailureActionsValidation.test.ts
PASS @stoplight/spectral-core     packages/core/src/__tests__/errorMessages.test.ts

It dies afterwards, in build-binary:

> Error! No available node version satisfies 'v18.20.8'

That is @yao-pkg/pkg@5.11.0 reporting it has no prebuilt Node 18.20.8 base for node18-windows. A packaging-toolchain gap, not a code failure. Tracked as #35.

So the accurate statement for this issue is: this build's tests pass on Linux, Windows and in the browser. What cannot currently be produced on Windows is the packaged binary at the pinned Node patch version. Those are different claims and the difference matters — one is about whether the software works, the other about whether we can ship an artifact.

Revised acceptance criteria

yarn install completes on a declared-supported Node version
yarn build completes
yarn test recorded — Jest and Karma pass on Node 18.20.8 and 20.20.0, in the browser, and on Windows
Node version stated — matrix is 18.20.8 and 20.20.0
Newest Node in the declared range — still open. >= 20.17 is open-ended and the matrix stops at 20.20.0.
A follow-up issue per failure — Windows: the test suite passes, but the binary build has no Node 18.20.8 target #35 (Windows packaging), fix(rulesets): wrap the four documentationUrl assertions prettier rejects #34 (lint, merged), The CI that now runs is misconfigured three ways: a hardcoded upstream path, CircleCI cache syntax, and a Windows job that can never fire #29 (CI config)

On the last open criterion

Upstream extended their matrix to 20.20.2, 22.23.2, 24.18.1 and 26.5.1 in 0dd45f14, and also touched the Dockerfile. That is the single most relevant thing to this issue in their tree, and it is now filed on our side by the watcher in #32 for an adopt-or-decline decision. Adopting it — or independently widening our own matrix — is what closes this issue out.

Worth noting the reason that criterion stayed open so long: locally, Node 25 cannot run this repo's own commit-message linter, and Node 25 no longer ships corepack, so the pinned yarn 3.5 needs the vendored release in .yarn/releases to work at all. Whatever the matrix says, "runs on current Node" is not free.

One more correction

My earlier comment reported lint as failing on README formatting. That was true then and fixed in #28. It failed again afterwards for a different reason — four over-width documentationUrl assertions I introduced in #27, which #27's own CI never reported because it failed earlier at install. Fixed in #34. Recording it here because the pattern matters more than either failure: main twice accepted changes CI had not actually cleared, which is #33.

fix(test-harness): run the built CLI, not a packaged binary (#48)

Run 2026-08-27. The fork builds and the tests pass. Every acceptance criterion below is checked except the one that needs a second machine.

Result

Step	Result
`yarn install --immutable`	pass
`yarn build`	pass — 219 JS files emitted across 10 packages
`yarn pretest && yarn test.jest`	pass — 200 of 200 suites, 1,966 tests passed, 1 skipped, 0 failed
`yarn test.karma` (browser)	pass — 1,859 of 1,859 in Chrome Headless 151
`yarn test.harness`	65 of 66 — the one failure is this machine, not the code. See below

Toolchain: Node v25.2.1, Yarn 3.5.0, macOS 25.5.0 / arm64.

The Node question the issue raised

The concern was that a 2023 toolchain would break on a recent Node major that satisfies >= 20.17 nominally. It does not. Node 25.2.1 is roughly five majors past anything this was tested against, and yarn 3.5.0, jest, karma and tsc --build all come up clean on it.

That is the newest Node available here, so the range is verified at its top end and at the two versions CI pins (18.20.8, 20.20.0). What is not verified is the bottom: engines still admits ^16.20, and nothing anywhere tests Node 16. It should be treated as unsupported in practice — see the README note added in #72. Narrowing engines is a breaking change and wants its own issue.

The one harness failure, in full

FAIL tests/help-no-document/help-no-document.test.js
  ● Errors when no document is provided
    script: illegal option -- f
    usage: script [-aeFkpqr] [-t time] [file [command ...]]

The harness wraps the CLI in script -f to get a TTY. -f is GNU script(1); macOS ships BSD script(1), which has no -f. The scenario is testing the harness's TTY wrapper, not the tool. CI runs these in Linux containers, where it passes. No follow-up issue — this is not a defect in this repository. Worth writing down only because the next person to run the harness on a Mac will hit it and wonder.

One trap worth knowing about

Running yarn test.jest on its own fails one suite:

FAIL packages/ruleset-migrator/src/__tests__/ruleset.test.ts
  Cannot find module ./__fixtures__/.cache/index.json

That fixture is generated by yarn pretest. CI runs pretest as a separate step so it never sees this, but anyone running the tests by hand from a clean checkout will. yarn pretest first, then it is 200/200.

Also: plain yarn test runs test.karma before test.jest, so on a machine without Chrome it fails at the browser suite before reaching the node suite. Set CHROME_BIN or run the two separately.

Acceptance criteria

yarn install completes on a declared-supported Node version
yarn build completes
yarn test result recorded — pass rate above, and the single non-passing case reproduced in full rather than summarised
The Node version used is stated, along with whether the newest Node in the declared range works — 25.2.1, and yes
If anything fails, a follow-up issue per failure — nothing failed that is a defect in this repository

This unblocks #1 and #11. It is a maintained build, not a source archive.

Navigation Menu

Repository navigation

Verify the fork builds and tests green #3

Acceptance criteria

The three failures, none of which are the test suite

What this issue was actually waiting on

Windows: the tests pass

Revised acceptance criteria

On the last open criterion

One more correction

Result

The Node question the issue raised

The one harness failure, in full

One trap worth knowing about

Acceptance criteria

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Verify the fork builds and tests green #3

Description

Activity

kinlane commented on Aug 3, 2026

kinlane commented on Aug 3, 2026

Acceptance criteria

The three failures, none of which are the test suite

What this issue was actually waiting on

kinlane commented on Aug 3, 2026

Windows: the tests pass

Revised acceptance criteria

On the last open criterion

One more correction

kinlane commented on Aug 27, 2026

Result

The Node question the issue raised

The one harness failure, in full

One trap worth knowing about

Acceptance criteria

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions