mirror of
https://github.com/JackChen-me/open-multi-agent.git
synced 2026-10-19 01:29:57 -05:00
Jack Chen
98516cedfc
A library that gets installed into someone else's backend is judged partly on what its own install pulls down. Three changes tighten that, and two questions turned out to need no change at all. The line this draws is what ships. Every dependency that stays inside the repository is now pinned to the exact version the lockfile already resolved: all 27 devDependencies across the four workspaces, plus the private release bot's own zod. The lockfile change is 28 spec lines with no resolution moved, no entry added or removed, and all 61 platform-specific entries intact. A new root .npmrc sets save-exact=true so the next one arrives pinned rather than as a range nobody notices. What a consumer installs keeps its range: `dependencies` in packages/core, the only published runtime block here, every `peerDependencies`, and otel's core compatibility range. An exact version in those blocks overrides the consumer's own resolution and stops their `npm audit fix` from reaching a patched build until we cut a release, which is a worse trade than the install-time drift it prevents. save-exact will still pin a new dependency added to one of them, so the package job now asserts all three published manifests and fails when one is left exact, next to the assertion that already covers otel's range. min-release-age is deliberately not set. It first shipped in npm 11.10.0, and the CI matrix runs Node 20 and 22, which bundle npm 10.8.2 and 10.9.8. Those two accept the key, echo it back from `npm config get`, and never act on it, so a quarantine window would hold on one leg of the matrix while silently doing nothing on the other two. It also has no effect on `npm ci`, which installs the lockfile verbatim. Every `npm ci` that installs this repository's own tree now passes --ignore-scripts, so a compromised dependency cannot run an install hook on a runner that holds release credentials. Only three dependencies declare a postinstall at all, and the full lint, test, build, scaffold, and example suites pass on a tree installed that way. The `npm install` calls that stand in for a real consumer are deliberately left alone: their job is to reproduce what a user's install actually does, and hardening them would make the smoke tests prove less than they claim. A new scheduled Supply chain audit workflow asks two questions about the dependencies that reach a consumer, an hour before the weekly release bot so a finding lands before the release PR is drafted. --omit=dev is the point of running it separately: auditing the full tree reports eighteen advisories, every one of them in test and fixture tooling that never ships, and a permanently red job is one nobody reads. The two steps fail differently. `npm audit` reports into the run summary, because a new upstream advisory is not this repository misbehaving and may have no fixed version yet. `npm audit signatures` fails, because it compares served bytes against the registry's own signature, so a mismatch is tampering rather than churn; all 27 production packages verify today. Two things needed no change. npm provenance is already live: publish.yml publishes through npm trusted publishing with id-token: write, which attaches SLSA attestations on its own, and every version since core 1.16.0, otel 0.1.2, and create-oma-app 0.8.1 carries one. And .npmrc left .gitignore in #198 because it only restated the default registry; it comes back tracked, with the ignore rule narrowed so a contributor's own nested .npmrc stays out.
31 lines
1.6 KiB
Plaintext
31 lines
1.6 KiB
Plaintext
# Repository-level npm configuration. It applies to every workspace and to
|
|
# contributors and CI alike.
|
|
|
|
# Save an exact version rather than a caret range when `npm install <pkg>`
|
|
# adds or upgrades a dependency, so an upgrade is always a reviewable diff
|
|
# instead of something a later install resolves on its own.
|
|
#
|
|
# The line this draws is what ships. Anything that stays inside the repository
|
|
# is pinned: every `devDependencies` entry, and the dependencies of the
|
|
# private release bot. Anything a consumer installs keeps a range, because an
|
|
# exact version there overrides their resolution and stops their own
|
|
# `npm audit fix` from reaching a patched build without waiting for a release:
|
|
#
|
|
# - `dependencies` in packages/core/package.json, the only published
|
|
# runtime block in the repository
|
|
# - every `peerDependencies` entry, which states what a consumer may bring
|
|
# - `@open-multi-agent/core` in packages/otel/package.json, which expresses
|
|
# core compatibility
|
|
#
|
|
# save-exact does not rewrite manifests that already carry a range, but it
|
|
# will pin a NEW dependency added to one of those blocks, so widen it by hand.
|
|
# The `package` job in ci.yml asserts both published blocks and fails if
|
|
# either is ever saved exactly.
|
|
save-exact=true
|
|
|
|
# `min-release-age` is deliberately absent. It first shipped in npm 11.10.0,
|
|
# and the CI matrix runs Node 20 and 22, which bundle npm 10.8.2 and 10.9.8.
|
|
# Those two would ignore the key without a word, so the quarantine window
|
|
# would hold on one leg of the matrix and not the other two. It also has no
|
|
# effect on `npm ci`, which installs the lockfile verbatim.
|