fix(build): ship npm-shrinkwrap.json in published package - #1622
Merged
Conversation
build.sh runs `npm shrinkwrap` before `npm pack`, but the package.json `files` allowlist omitted npm-shrinkwrap.json, so npm pack dropped it and every release shipped with unpinned `^` dependency ranges. Consumers then resolved native-addon deps to whatever satisfied the range at install time (e.g. @datadog/pprof floating onto a build-broken 5.16.0), while harper-pro — whose files array already lists npm-shrinkwrap.json — installed cleanly. Add npm-shrinkwrap.json to files so the generated lockfile reaches the tarball and consumers get the pinned tree. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
Contributor
|
Reviewed; no blockers found. |
kriszyp
marked this pull request as ready for review
July 6, 2026 20:58
Member
Author
|
CI note: the 3 unit failures ( (AI-generated note — Claude Opus 4.8) |
Ethan-Arrowood
approved these changes
Jul 10, 2026
Ethan-Arrowood
left a comment
Ethan-Arrowood
left a comment
Member
There was a problem hiding this comment.
LGTM
sent with Claude Fable 5
kriszyp
pushed a commit
that referenced
this pull request
Jul 13, 2026
Follow-up to #1622. npm shrinkwrap runs after a full npm install in build-tools/build.sh, so the generated npm-shrinkwrap.json captures devDependencies as well as runtime ones. Since #1622 started shipping npm-shrinkwrap.json in the published tarball, consumers now get harper's entire dev tree installed under node_modules/harper/node_modules/ -- including esbuild (pulled in transitively via tsx) and its ~30 platform-specific optional binaries. Those nested @esbuild/<platform> entries land in the consumer's package-lock.json as "extraneous" rather than resolved-optional, because they aren't reachable from any declared dependency edge in the consumer's graph -- they're just mirrored in from harper's bundled shrinkwrap. Extraneous entries don't get the "optional": true flag written, so npm ci in consumer projects fails with EBADPLATFORM on platforms other than the shrinkwrap's original build machine (e.g. @esbuild/aix-ppc64 on darwin/arm64). Prune devDependencies before shrinkwrapping so the pinned tree only contains what harper actually needs at runtime. Co-authored-by: Peter Brumblay <pbrumblay@users.noreply.github.com>
github-actions Bot
pushed a commit
that referenced
this pull request
Jul 13, 2026
Follow-up to #1622. npm shrinkwrap runs after a full npm install in build-tools/build.sh, so the generated npm-shrinkwrap.json captures devDependencies as well as runtime ones. Since #1622 started shipping npm-shrinkwrap.json in the published tarball, consumers now get harper's entire dev tree installed under node_modules/harper/node_modules/ -- including esbuild (pulled in transitively via tsx) and its ~30 platform-specific optional binaries. Those nested @esbuild/<platform> entries land in the consumer's package-lock.json as "extraneous" rather than resolved-optional, because they aren't reachable from any declared dependency edge in the consumer's graph -- they're just mirrored in from harper's bundled shrinkwrap. Extraneous entries don't get the "optional": true flag written, so npm ci in consumer projects fails with EBADPLATFORM on platforms other than the shrinkwrap's original build machine (e.g. @esbuild/aix-ppc64 on darwin/arm64). Prune devDependencies before shrinkwrapping so the pinned tree only contains what harper actually needs at runtime.
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
2 participants
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
Add
npm-shrinkwrap.jsonto thefilesallowlist inpackage.json.Why
build-tools/build.shalready runsnpm shrinkwrapbeforenpm pack, intending to ship a pinned dependency tree. Butpackage.jsondeclares afilesallowlist, and that list omittednpm-shrinkwrap.json— sonpm packsilently dropped the generated lockfile. Result: every published harper release has shipped with unpinned^ranges, and consumers resolve native-addon deps to whatever satisfies the range at install time.Concretely:
npm install harper@5.0.31floats@datadog/pprof(^5.11.1) onto 5.16.0, whose tarball failsnode-gyp rebuild(binding.gyp not found).@harperfast/harper-pro@5.0.31installs cleanly precisely because itsfilesarray already listsnpm-shrinkwrap.json, so its shrinkwrap ships and pins pprof to 5.14.1.Effect
Future releases from this branch ship the shrinkwrap
build.shalready generates, so consumers get the exact pinned tree (rocksdb-js, lmdb, argon2, …).Where to look
npm pack --dry-run:npm-shrinkwrap.jsonis now listed in the tarball (it was excluded before).Generated by Claude (Opus 4.8).