Repository navigation
pnpm: use node-lts runtime, frozen-lockfile installs - #97
Merged
Merged
Conversation
pnpm releases are built against Node LTS, and most hosting providers default to LTS as well. Match that baseline so the harness runtime mirrors what pnpm is tested on and what users deploy with. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
1 task
Contributor
There was a problem hiding this comment.
I think we also need to update the pnpm package, which declares a runtime dependency on node explicitly:
Line 21 in eac36d4
pnpm releases are built against Node LTS and most hosting providers default to LTS, so switch both the pnpm harness runtime and the pnpm package's runtime_deps to node-lts. Also tighten the harness install step: when pnpm-lock.yaml is present, use --frozen-lockfile for reproducibility (pnpm's equivalent of npm ci), falling back to plain install otherwise. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
twitchyliquid64
approved these changes
Apr 22, 2026
bryan-minimal
added a commit
that referenced
this pull request
Aug 4, 2026
Follows Tom's review on #370 — "I dont think a global `node_modules` is gonna go so well, particularly if someone uses `node` vs `node-lts`". The collision half of that was already handled: vlt installs into a private `usr/libexec/vlt` prefix with relative PATH symlinks, never the shared `usr/lib/node_modules` the node runtime owns. But the variant question the comment raises was still answered by the importer's hardcoded default rather than by evidence. The evidence says LTS: - vlt's own CI tests Node 22.x ONLY (`node-version: '^22.22.0'` and `[22.x]`); `engines` says `>=22.22.0`. Our node-lts is 24.14.1 and node is 25.8.2 — neither is 22.x, but LTS is two majors closer to what upstream actually tests against. - pnpm is the closest analogue in this repo (a package manager, a node CLI, same shape of package) and it is on node-lts, per #97/#98: the node most users and hosting providers run is whatever ships with current LTS. node-lts ships its own npm, so it serves the build (`npm ci`) and the runtime (`#!/usr/bin/env node`) both — no split between build_deps and runtime_deps. Rebuilt and re-checked on the min path: 15/15 Pass.
lrishi
pushed a commit
to lrishi/gominimal-pkgs
that referenced
this pull request
Aug 15, 2026
…ominimal#564) * vlt: package the vlt package manager from npm (BSD-2-Clause-Patent) vlt 1.0.1 shipped today (vltpkg/vltpkg). Seeded with `pkgmgr import npm vlt` and refined by hand for the two things discovery mode can't know. Why this one is unusually clean to package: the published tarball has **zero dependencies**. `npm ci` against the committed lockfile installs exactly one package, pinned by version + integrity — no transitive tree, no native addons, no compile step. `npm audit` in-build reports 0 vulnerabilities across the whole 2-package graph. Two changes on top of the generated files: - **Bins enumerated, not globbed.** The importer emits `bins = { glob = "usr/bin/*" }`, which trips the `enumerate bins` checker for any package with a handful of bins — vlt has five (`vlt`, plus the documented shorthands `vlr`/`vlx` and their variants). The npm registry metadata lists them exactly, so nothing had to be inferred. Fixing this in the importer is pkgmgr-rs follow-up work, not a one-off. - **Real standalone tests.** The generated package had none, and `standalone tests...Pass` is what the checker reports for a package with zero tests — so "Pass" out of the box meant nothing. Added three that exercise the artifact rather than the build inputs: * `version_is_exact` — string equality against `%{version}`, not `--version | grep`. vlt's usage banner also carries the version, so a grep would pass on a build where `--version` is broken and only usage prints. * `companion_bins_work` — all four shorthands. They are PATH symlinks into the private libexec prefix; a broken relative link fails here and nowhere else. * `reads_a_manifest` — `vlt pkg get name` against a fixture package.json. Real offline work through the bundled JS; a truncated install still prints `--version` and fails this. Mutation-tested: flipping the expected version to `0.0.0-mutant` turns the suite red with `version_is_exact ... had exit code 1`, so these can fail for the reason they exist. **No `source_provenance`, deliberately.** vlt's vuln identity is its npm package name. minimal-supply-chain routes a node-flavored package with no provenance to `pkg:npm/<name>` (`scan.rs::npm_purl_for_node_package`) where the OSV/GHSA npm advisories resolve. Declaring `GithubRepo vltpkg/vltpkg` would move it onto the repo-purl arm, where GHSA's npm advisories — keyed by package name, not repo — would stop matching. Absent is correct here. Built and checked with the min-native path (`min package build` side-op + `min check`), 15/15 Pass. * vlt: build and run against node-lts, not node Follows Tom's review on gominimal#370 — "I dont think a global `node_modules` is gonna go so well, particularly if someone uses `node` vs `node-lts`". The collision half of that was already handled: vlt installs into a private `usr/libexec/vlt` prefix with relative PATH symlinks, never the shared `usr/lib/node_modules` the node runtime owns. But the variant question the comment raises was still answered by the importer's hardcoded default rather than by evidence. The evidence says LTS: - vlt's own CI tests Node 22.x ONLY (`node-version: '^22.22.0'` and `[22.x]`); `engines` says `>=22.22.0`. Our node-lts is 24.14.1 and node is 25.8.2 — neither is 22.x, but LTS is two majors closer to what upstream actually tests against. - pnpm is the closest analogue in this repo (a package manager, a node CLI, same shape of package) and it is on node-lts, per gominimal#97/gominimal#98: the node most users and hosting providers run is whatever ships with current LTS. node-lts ships its own npm, so it serves the build (`npm ci`) and the runtime (`#!/usr/bin/env node`) both — no split between build_deps and runtime_deps. Rebuilt and re-checked on the min path: 15/15 Pass. * vlt: record why this is a registry artifact, not a source build AGENTS.md requires a prebuilt fallback be called out explicitly. The reason here is not "nobody tried" — source IS published (7.4 MB tarball, 48 real TypeScript workspaces), it just cannot be built with a toolchain we have. Measured against the extracted tarball: npm -> EUNSUPPORTEDPROTOCOL: Unsupported URL Type "catalog:" pnpm -> ERR_PNPM_CATALOG_ENTRY_NOT_FOUND_FOR_SPEC Dependency specs use the `catalog:` protocol with the catalog declared in `vlt.json`; pnpm supports catalogs but reads pnpm-workspace.yaml. The only lockfile is `vlt-lock.json` (vlt's own format), and `package.json` has no `workspaces` key, so neither tool can see the monorepo layout. Upstream CI agrees: setup-vlt@v1 then `vlt install`. The published package declares `bin: null`, no deps, and one script — `prepack: vlt-build-prepack`. Building vlt from source requires vlt. That bootstrap cycle is the "required toolchain genuinely isn't packaged yet" case AGENTS.md carves out; breaking it means a two-stage vlt-bootstrap -> vlt pair in the gawk-bootstrap shape, worth doing if vlt becomes load-bearing and not before. Comment-only. Rebuilt and re-checked: 15/15 Pass.
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Summary
runtime_packagesfromnodetonode-lts.runtime_depsfromnodetonode-ltsto match.pnpm install --frozen-lockfilewhenpnpm-lock.yamlis present, falling back to plainpnpm installotherwise.Reasoning
node-lts: pnpm's own releases are built against Node LTS, and most hosting providers default to LTS for Node runtimes. Aligning both the harness runtime and the pnpm package's declared runtime with LTS matches what pnpm is tested against upstream and what users are most likely to deploy on.
--frozen-lockfile: Mirrors the npm harness's
npm cibehavior — when a lockfile is checked in, installs should be reproducible and fail loudly if the lockfile drifts frompackage.json. Falls back to plainpnpm installwhen no lockfile is present (e.g. a workspace root matched only bypnpm-workspace.yaml).Test plan
min check --harnesses pnpmmin check --packages pnpm🤖 Generated with Claude Code