Repository navigation
🏗️✨:check the runtime pins still agree - #1888
Conversation
Ported from OpenINF/.github, where this landed as 966b995. Three files name a version and all three have to say the same thing: .nvmrc is what nvm reads for a bare `nvm use`, `engines` is what pnpm enforces and what setup-node is pointed at, and `packageManager` is the version pnpm fetches to run as. Only one of those pairs was guarded, and only in the dev container. post-create.sh compares .nvmrc against `engines.node` and stops if they differ, but it runs when somebody builds a container and nowhere else. CI reads package.json alone, so a change that moved one and left the other would pass every check and then fail for the next person to open the container. The `packageManager` and `engines.pnpm` pair had nothing watching it at all, and it is the worse of the two: pnpm fetches the version the first names and then holds itself to the second, so a disagreement fails every install rather than one shell. `engineStrict` is checked as well, because everything else here rests on it. Without it `engines` is a note rather than a requirement, and a task that confirmed three files agree would be reporting success over a promise nothing keeps. The task reads only what node ships with, so it runs before anything is installed. post-create.sh is left alone here; the dev container port that rewrites it is what makes it call this rather than repeat it. Checked here: Node 24.20.0 and pnpm 11.25.0 agree across all three files. Verified it is not passing vacuously by moving .nvmrc to 24.19.0, which it reported with exit 1. Signed-off-by: Derek Lewis <DerekNonGeneric@inf.is> Assisted-by: Claude-Code:claude-opus-5
✅ Deploy Preview for gh-pages-openinf ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Team Run ID: 📒 Files selected for processing (2)
Included review availability: Your plan provides up to 8 included reviews per hour; 6 remain after this review. 📝 WalkthroughWalkthroughThe PR adds a runtime verification script. It cross-checks Node and pnpm versions across ChangesRuntime consistency verification
Estimated code review effort: 3 (Moderate) | ~20 minutes Merge Risk: ⚪ Minimal · up to This adds a runtime pin consistency check that reports configuration mismatches before dependent tooling runs. The current implementation is ready to merge with no identified active risk. Sequence Diagram(s)sequenceDiagram
participant PackageTask as package-scripts.yml
participant VerifyRuntimes as verify-runtimes.mts
participant RuntimeFiles as Runtime configuration files
PackageTask->>VerifyRuntimes: run runtimes verification task
VerifyRuntimes->>RuntimeFiles: validate and compare configured versions
RuntimeFiles-->>VerifyRuntimes: return runtime configuration
VerifyRuntimes-->>PackageTask: report problems or successful versions
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
Ported from
OpenINF/.github, where this landed as966b995.Three files name a version and all three have to say the same thing:
.nvmrcis what nvm reads for a barenvm use,enginesis what pnpm enforces and whatsetup-nodeis pointed at, andpackageManageris the version pnpm fetches to run as.Only one of those pairs was guarded, and only in the dev container.
post-create.shcompares.nvmrcagainstengines.nodeand stops if they differ, but it runs when somebody builds a container and nowhere else. CI readspackage.jsonalone, so a change that moved one and left the other would pass every check and then fail for the next person to open the container.The
packageManager/engines.pnpmpair had nothing watching it at all, and it is the worse of the two: pnpm fetches the version the first names and then holds itself to the second, so a disagreement fails every install rather than one shell.engineStrictis checked as well, because everything else rests on it. Without itenginesis a note rather than a requirement, and a task confirming three files agree would be reporting success over a promise nothing keeps.How it was checked
engineStrict: trueis at column zero inpnpm-workspace.yaml..nvmrcto24.19.0is reported with exit 1.# commentafterengineStrict: trueis still accepted, as intended.node:fs/promises, so it runs before anything is installed — which is what letspost-create.shcall it.Ordering
verify.workflows.post-create.shcalls this task instead of repeating the comparison.Summary by CodeRabbit