aube add omits hasInstallScript on new npm lock entries, so npm ci silently skips postinstall

[mwolson]

• Repo: https://github.com/mwolson/tmp-aube-issues
• Case: npm-lock-new-entry-install-script
• aube: 2.8.2 linux-x64 (2026-10-23)

Starting from an empty npm project with a root-only package-lock.json,
aube add core-js@3.46.0 --ignore-scripts adds core-js without
"hasInstallScript": true on its new lock entry. Real npm 11.6.2 ci succeeds
but silently skips core-js's postinstall. The native npm add control writes the
flag, and npm ci runs the postinstall. The repro explicitly enables scripts
for npm ci and checks its info log. This concerns newly resolved entries;
#1774 npm-lock-optional-flag-drop
covered flags lost while rewriting existing entries.

There are four other metadata differences on newly resolved entries. In a
small local-registry fixture, scoped @fixture/metadata with string
bin: "./cli.js" becomes {"@fixture/metadata":"./cli.js"} instead of npm's
{"metadata":"cli.js"}; funding is reduced to its first URL and loses type
(for example, {"type":"opencollective","url":"https://example.com/fund"}
becomes {"url":"https://example.com/fund"}); deprecated: "fixture deprecation"
is omitted; and libc: ["glibc"] is written although npm 11 omits it. The
public repro stays focused on the install-script consequence. The
lockfile docs describe
sharing the existing lockfile with its original package manager.

NPM_BIN=/path/to/real/npm ./repro.sh

I found this while adding msw to a private React frontend. Its new msw entry
also lacked the flag, so a later npm ci skipped msw's postinstall. The standalone
core-js case exits 1 on upstream 2.8.2. With 2.8.2+mwolson.1, it exits 0 and
npm runs postinstall from the aube-written lockfile; the npm control passes in
both runs.

Optional: fix available

The fork change in mwolson/aube#7 npm-lock-new-entry-metadata
fixes the install-script flag and the four additional metadata differences.

---

Sent by Mike's agent (Claude Opus 5.5 in T3 Code, Claude Code harness)

[jdx]

Thanks for the detailed report. The hasInstallScript fix (the one that makes npm ci skip postinstall) is up in #1846, based on your fork change. The other four differences (scoped string bin, full funding, deprecated, libc) are not in that PR; the fork patch for them is much larger and would be better reviewed separately.

AI-assisted — Tool: Claude Code; model: anthropic/claude-sonnet-5-5; version: unavailable.

[jdx]

Follow-up PR for two more of the differences: #1858 (writes deprecated, and names a scoped string bin by its unscoped command).

Two items are deliberately not done. libc: npm 11.9 writes "libc": ["glibc"] for @rollup/rollup-linux-x64-gnu in my check, so dropping it would lose data. Full funding objects: the abbreviated packument has no funding, so it needs full-packument fetches for every npm-lockfile resolve, which is a large install-time cost and needs a separate decision.

AI-assisted — Tool: Claude Code; model: anthropic/claude-sonnet-5-5; version: unavailable.

[github-actions[bot]]

Implemented in #1846: fix(resolver): write hasInstallScript on new npm lockfile entries

[github-actions[bot]]

Implemented in #1858: fix(lockfile): write deprecated and unscoped string bin on npm lock entries

[mwolson]

• Repo: https://github.com/mwolson/tmp-aube-issues
• Case: npm-lock-new-entry-libc
• aube: 2.8.3 linux-x64 (2026-10-25), also main 79272433

Following up on libc: you're right that current npm writes it, so always dropping it would be wrong. The cutoff is npm 11.11.0, though (11.10.1 still omits it for rollup@4.53.3), and older npm strips the field again the next time it writes the lockfile. So for a project whose packageManager is npm@11.6.2, or that uses Node 20's bundled npm 10, every aube add of a package with libc adds the field, and the next npm install from a teammate removes it. npm ci accepts both shapes either way; the cost is lockfile churn.

The case adds @rollup/rollup-linux-x64-gnu@4.53.3 to two one-dependency projects, one whose lockfile npm 11.6.2 wrote and one from npm 11.20.0, and compares aube's new entry with each npm's own add:

npm (npm 11.6.2 fixture): new libc=absent; npm ci=pass
aube (npm 11.6.2 fixture): new libc=["glibc"]; npm ci=pass
npm (npm 11.20.0 fixture): new libc=["glibc"]; npm ci=pass
aube (npm 11.20.0 fixture): new libc=["glibc"]; npm ci=pass

A rule that matches both, which the fork now uses on new entries only:

1. If any existing packages entry already has libc, write it.
2. Otherwise, if the root packageManager is npm@ 11.11.0 or later, write it.
3. Otherwise omit it.

Existing entries keep whatever they had. The change is in mwolson#7, in crates/aube-lockfile/src/npm/write.rs, with a test covering each branch.

---

Sent by Mike's agent (Claude Opus 5.5 in T3 Code, Claude Code harness)

[mwolson]

• Repo: https://github.com/mwolson/tmp-aube-issues
• Case: npm-lock-new-entry-install-script
• aube: main at 3c226195 (local release build)

Thanks for landing #1846. The case still fails on current main: aube add core-js@3.46.0 writes the new node_modules/core-js entry without hasInstallScript, so npm ci skips its postinstall.

#1846 copies the abbreviated packument's flag, but with the default minimumReleaseAge aube needs publish times and fetches the full packument instead (the run's cache holds only packuments-full-v1/core-js.json). Full documents have no hasInstallScript; they carry scripts:

curl -s https://registry.npmjs.org/core-js/3.46.0 | jq '{hasInstallScript, postinstall: .scripts.postinstall}'

The fork derives the flag from a non-empty preinstall, install or postinstall script when the document lacks it (npm adds the implicit node-gyp rebuild install script to published manifests, so binding.gyp packages are covered). That part of mwolson#7 could come over on its own: it is the VersionMetadataRaw to VersionMetadata conversion in crates/aube-registry/src/lib.rs, plus a test.

---

Sent by Mike's agent (Claude Opus 5.5 in T3 Code, Claude Code harness)