Repository navigation
Conversation
mwolson
force-pushed
the
contrib/npm-lock-new-entry-metadata
branch
from
October 25, 2026 00:54
d687b90 to
6fa2023
Compare
mwolson
force-pushed
the
contrib/npm-lock-new-entry-metadata
branch
from
October 25, 2026 03:08
6fa2023 to
eab2dbe
Compare
mwolson
force-pushed
the
contrib/npm-lock-new-entry-metadata
branch
from
October 25, 2026 17:27
eab2dbe to
a3ec6ee
Compare
jdx
added a commit
to aubepkg/aube
that referenced
this pull request
Oct 25, 2026
) <!-- entire-trail-link-start --> https://entire.com/gh/aubepkg/-/trails/203/changes/aube/203 <!-- entire-trail-link-end --> ## Problem When `aube add` (or any resolve) adds a new package to an npm `package-lock.json`, the new entry never gets `"hasInstallScript": true`, even when the package declares install scripts. `npm ci` only runs a dependency's `preinstall`/`install`/`postinstall` when that flag is present, so a lockfile written by aube makes npm silently skip them. Reported in [discussion #1824](#1824). ```sh # package-lock.json is an empty root-only npm lockfile aube add core-js@3.46.0 --ignore-scripts npm ci --foreground-scripts # core-js postinstall should run ``` **Before:** the `node_modules/core-js` entry has no `hasInstallScript`, and `npm ci` skips its postinstall. **After:** the entry carries `"hasInstallScript": true`, matching what `npm install` writes, so `npm ci` runs the postinstall. Entries that were already in the lockfile were already preserved; this only affects newly resolved ones. ## Change The packument's `hasInstallScript` was already parsed but dropped at resolve time. The resolver now records it in the package's `extra_meta` (next to `deprecated`), which the npm writer already reads. One resolver test covers a package with and without the flag. ## Not included The discussion also lists four other differences on new npm entries: scoped string `bin` naming, complete `funding` objects, `deprecated`, and `libc` being written. They are left out here: the fork patch for them is much larger (full-metadata packument fetching, registry cache format changes) and deserves its own review. Note `deprecated` is already recorded in `extra_meta` by the resolver; the npm writer just does not emit it yet. ## Validation - `cargo test -p aube-resolver -p aube-lockfile`, `cargo fmt --check` - `cargo clippy -p aube-resolver --all-targets -- -D warnings` (workspace-wide clippy hit an unrelated mbx build-script shim error in this environment, so I ran it for the changed crate only) - Not run: bats, and a real `npm ci` against an aube-written lockfile. Based on mwolson's fork change (mwolson#7). *AI-assisted — Tool: Claude Code; model: anthropic/claude-sonnet-5-5; version: unavailable.* 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> <!-- coderabbit-ai-generated:v1 --> ## Summary by CodeRabbit * **New Features** * Resolved package information now records when a package declares an install script, alongside existing registry deprecation details. The install-script indicator is included when the package metadata marks it as present and omitted otherwise. This makes the declaration available consistently in the results of a fresh package resolution. <!-- end of auto-generated comment: release notes by coderabbit.ai --> Co-authored-by: Mike Olson <mwolson@member.fsf.org> Co-authored-by: Claude Sonnet 5.5 <noreply@anthropic.com>
mwolson
force-pushed
the
contrib/npm-lock-new-entry-metadata
branch
from
October 25, 2026 21:33
a3ec6ee to
90bcde4
Compare
mwolson
changed the base branch from
contrib/npm-lock-peer-entries
to
contrib/pnpm-lock-peer-suffix-shape
October 26, 2026 01:07
mwolson
force-pushed
the
contrib/npm-lock-new-entry-metadata
branch
from
October 26, 2026 01:07
90bcde4 to
8c5bec9
Compare
jdx
added a commit
to aubepkg/aube
that referenced
this pull request
Oct 26, 2026
…ct's npm does (#1874) <!-- entire-trail-link-start --> https://entire.com/gh/aubepkg/-/trails/230/changes/aube/230 <!-- entire-trail-link-end --> Adding a package that declares `libc` (for example `@rollup/rollup-linux-x64-gnu`) always wrote `"libc": [...]` on its new npm lockfile entry. npm only started writing that field in 11.11.0, and older npm strips it on the next write, so teammates on npm 10 or 11.6 got lockfile churn after every `aube add`. `npm ci` accepts both shapes. A new entry now gets `libc` only when the project's npm would write it: 1. any entry in the existing `package-lock.json` already has `libc`, or 2. the root `packageManager` is `npm@11.11.0` or later. Otherwise it is omitted. Entries already in the lockfile keep whatever they had. ```json { "packageManager": "npm@11.6.2" } ``` With this manifest, `aube add @rollup/rollup-linux-x64-gnu` no longer adds `libc` to the lockfile; with `npm@11.20.0` it does. Based on the rule proposed in the discussion (mwolson#7). Tests cover each branch plus existing entries; `cargo test -p aube-lockfile` and clippy pass. Not run against real npm here. Discussion: #1824 (comment) *AI-assisted — Tool: Claude Code; model: anthropic/claude-sonnet-5-5; version: unavailable.* 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> <!-- coderabbit-ai-generated:v1 --> ## Summary by CodeRabbit * **Bug Fixes** * npm lockfiles now preserve nonempty `libc` metadata for existing package entries. Existing entries without this metadata remain without it, including when adding an alias of the same package. * New package entries include `libc` metadata when the project specifies npm 11.11.0 or later. Older or unspecified npm versions and pnpm omit the metadata by default. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Sonnet 5.5 <noreply@anthropic.com>
Retain complete funding and derive install-script metadata from full packuments. Match the project's libc lockfile convention while retaining install-time platform constraints and imported libc presence and shape. Only a plain npm semver pin at or above 11.11.0 opts into new libc fields when the existing lockfile has no libc metadata. Normalize executable names and paths only when writing npm lockfiles; keep registry paths unchanged on the graph for other lockfile formats. Retain implicit-name executables across compact cache writes and reads, including older sentinel maps. Rehydrate empty object keys as the package command before each writer applies its format's bin handling. Skip npm-only entry, bundle, retained-entry and workspace metadata when writing bun.lock.
mwolson
force-pushed
the
contrib/npm-lock-new-entry-metadata
branch
from
October 30, 2026 15:54
8c5bec9 to
4681743
Compare
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
New
package-lock.jsonentries written by aube now carry the metadata npmwrites:
hasInstallScripteven when aube resolved from full packuments, plusnormalized
binand fullfunding. A later realnpm citherefore runs thepackages' install scripts. aube's internal npm metadata also stays out of
bun.lock. Upstream#1846 npm-lock-new-entry-install-script
records the abbreviated packument's flag,
#1858 npm-lock-new-entry-bin-deprecated
writes
deprecated, and#1874 npm-libc-rule decides when
libcis written; this layer covers full packuments, the remaining fields andsmall additions to that
libcrule.Problem and Fix
minimumReleaseAge, aube resolves from full packuments, which carryscriptsand nohasInstallScript, so new entries still lacked the flag andnpm ciskipped install scripts (core-js, msw).preinstall,installorpostinstallscript, including npm's implicitnode-gyp rebuild, and upstream's insertion writes it.binas./cli.js(npm writes{"metadata": "cli.js"}) and kept only the first funding URL.binnormalization runs only in the npm writer (other lockfile formats keep upstream's shape), and funding is kept as published.__aube_npm_bundled_optionalin itsbun.lockmetadata slot, which Bun never writes and drops on its next install.libcrule ignores an existinglibcfield that is empty or a scalar, and accepts a loose version inpackageManager.libcfield counts as the lockfile using it, only a plain semver pin selects npm's convention, and existinglibcfields stay as written.Validation
npm-lock-new-entry-install-scriptandbun-lock-npm-bundled-optional-metapass (both fail on upstreamv2.8.4), andnpm-lock-new-entry-libcpasses.aube addof a package withlibcis byte-identical to npm withpackageManagerpins 11.20.0, 11.6.2 and none.npm ciruns msw's postinstall.
dependency to an existing npm lockfile, and 0 to 7 percent on medians for a
whole-tree
update --lockfile-only, within network noise.