Repository navigation
8000
npm harness: use node-lts for runtime - #98
Merged
Merged
Conversation
npm is bundled with Node, so the npm most users and hosting providers run is whichever ships with the current LTS. Match that baseline so the harness runtime mirro 8000 rs what the ecosystem is tested on and what users deploy with. 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.Reasoning
npm is bundled with Node, so the npm version most users and hosting providers run is whichever ships with the current Node LTS. Aligning the harness with LTS matches what the ecosystem is tested against and what users are most likely to deploy on. Mirrors #97 for pnpm.
Test plan
min check --harnesses npm🤖 Generated with Claude Code