-
-
Notifications
You must be signed in to change notification settings - Fork 161
fix(test): harden gap snapshot oracle inputs #9306
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
proggeramlug
merged 2 commits into
PerryTS:main
from
proggeramlug:fix/9273-gap-snapshot-gate
Aug 31, 2026
Merged
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,20 @@ | ||
| ### Fixed — gap snapshots now require a valid Node oracle | ||
|
|
||
| The nine regressions reported by a pristine-main gap run in #9273 were two | ||
| different artifacts. Five package-backed fixtures ran without the root | ||
| `npm ci`, so Node printed `ERR_MODULE_NOT_FOUND` while Perry produced valid | ||
| output. Four were genuine #9244 regressions that #9247 had already fixed, but | ||
| the stale run still presented them as current failures. The committed Linux | ||
| baseline remains the five failures reproduced by the pinned oracle. | ||
|
|
||
| `run_gap_tests.sh` now stops before building unless `node --version` exactly | ||
| matches `.node-version` and `npm ls --depth=0` confirms the committed root | ||
| dependency graph is present. Node is the byte-for-byte reference output, so a | ||
| different patch release or missing package is a different experiment rather | ||
| than evidence of a Perry regression. Both failure paths explain how to restore | ||
| the required environment. | ||
|
|
||
| Snapshot refreshes now copy existing issue/date/category/reason metadata from | ||
| `known_failures.json`, and the required offline audit checks the relationship | ||
| in both directions: every accepted Linux snapshot failure must have a | ||
| Linux-applicable, issue-backed known-failure entry. The formerly anonymous |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
🔎 Supported by static analysis
🏁 Script executed:
Repository: PerryTS/perry
Length of output: 43061
🌐 Web query:
npm documentation npm ls verifies installed tree package.json lockfile npm ci exact package-lock behavior💡 Result:
The npm ls command and npm ci command serve distinct purposes in managing and verifying dependency trees. npm ls The npm ls command lists installed packages and their dependencies in a tree structure [1]. It identifies extraneous, missing, and invalid packages based on the logical dependency tree rather than the physical layout of the node_modules folder [1][2]. By default, npm ls operates on the currently installed node_modules [1][3]. If an error exists in the dependency tree, such as unmet peer dependencies, npm ls will report them and exit with a non-zero exit code [4]. While npm ls displays the installed tree, it does not inherently act as a "verify against package.json and lockfile" command in the same way that npm ci ensures environment parity [1][5]. However, it can be used to detect discrepancies if the current node_modules do not align with dependency requirements [1]. You can also use the --package-lock-only flag to have npm ls output the tree described by the package-lock.json instead of the actual contents of node_modules [1][6][7]. npm ci The npm ci command is specifically designed for automated environments where a clean, predictable install is required [8][9]. Its behavior regarding package.json and package-lock.json is strict: - Requirement: The project must have an existing package-lock.json (or npm-shrinkwrap.json) [5][8]. - Verification: It verifies that the dependencies in the lockfile match those in package.json [5][8]. If they do not match, npm ci will exit with an error rather than updating the lockfile [5][8]. - Consistency: It ensures the installed tree matches the package-lock.json exactly [5][10]. If a node_modules folder already exists, it is removed before the install begins [5][8]. - Immutability: It never updates package.json or package-lock.json; the installation is essentially frozen [5][8]. In summary, npm ci is the authoritative tool for enforcing that your installed dependencies match your lockfile and package.json exactly, while npm ls is a diagnostic tool for inspecting the current state of your node_modules tree [1][5].
Citations:
🏁 Script executed:
Repository: PerryTS/perry
Length of output: 32199
Enforce the lockfile dependency tree before running the suite.
npm ls --depth=0checks installed packages againstpackage.jsonranges. It does not require the installed tree to matchpackage-lock.json. A semver-compatible version such as a differentcronrelease can pass while package-backed gap fixtures produce different output. Runnpm ci --ignore-scripts --no-audit --no-fund, or add an equivalent lockfile-aware check, before the suite.🤖 Prompt for AI Agents