[pull] latest from npm:latest#10
Open
pull[bot] wants to merge 2031 commits into
Open
Conversation
|
fritzy
force-pushed
the
latest
branch
3 times, most recently
from
3037d35 to
f3b0c43
Compare
lukekarrys
force-pushed
the
latest
branch
2 times, most recently
from
591d1d1 to
9e74d3e
Compare
owlstronaut
force-pushed
the
latest
branch
2 times, most recently
from
85ec0c9 to
26b6454
Compare
…h prepare - Updated examples section to use prepare and test scripts instead of discouraged install/postinstall - Changed use case recommendations from prepublish to prepare - Replaced CoffeeScript example with TypeScript (more current) - Replaced make commands with modern build tools (tsc, jest) - Fixes #3992
## WHY/WHAT Fixed non-intuitive unit rounding for byte formatting. Previously, values close to a unit boundary (e.g. 999,999 B) displayed incorrectly as the smaller unit. We adjusted the conversion threshold (e.g. to 999,950 B for MB) to leverage standard `toFixed(1)` rounding, ensuring values that are `almost 1.0` of the next unit are correctly displayed as 1.0 MB, prioritizing a better user experience.
Adds proxy-related environment variables to npm config list output to help users understand their proxy configuration. Variables are checked case-insensitively to match the agent library behavior. Closes #4170
As mentioned in the issue #8837, BOM files in cyclonedx format created by npm-sbom contain an invalid statically UUID value in the serialNumber field: `"serialNumber": "urn:uuid:***"`, because it was being redacted each time. This change uses `output.standard()` with `{ [META]: true, redact: false }` to bypass redaction for SBOM output, following the same pattern used in `lib/commands/token.js` for outputting authentication tokens that should not be redacted. **Before:** ```json "serialNumber": "urn:uuid:***" ``` **After:** ```json "serialNumber": "urn:uuid:12345678-1234-1234-1234-123456789abc" ``` <img width="1265" height="518" alt="image" src="https://github.com/user-attachments/assets/fc21aa65-2bef-4336-a55c-e7417ae9eebd" /> ## Testing - All existing tests pass - Verified locally that `serialNumber` now displays the complete UUID ## References Fixes #8837
## Description This PR adds documentation explaining how `npm install` behaves with respect to `package.json` and `package-lock.json`, a common source of confusion for npm users. ## Changes - Added a new section "How `npm install` uses `package-lock.json`" to the `npm install` documentation - Explained the two scenarios: - When `package.json` and `package-lock.json` are in sync: exact versions from lockfile are installed - When they conflict: `package.json` wins and `package-lock.json` is updated - Clarified that `package.json` is the source of truth for version ranges, while `package-lock.json` locks to specific versions - Noted the relationship to `npm ci` behavior ## Context The npm install documentation previously didn't explain how it handles the interaction between `package.json` and `package-lock.json`. Users were confused about when versions from the lockfile are used versus when they're updated. This PR incorporates the explanation from Kat Marchán that was referenced in the issue to provide clear guidance. Closes #4866 Co-authored-by: Max Black <husivm@google.com>
<!-- What / Why --> <!-- Describe the request in detail. What it does and why it's being changed. --> while reading https://docs.npmjs.com/cli/v11/commands/npm-dedupe <img width="1582" height="502" alt="image" src="https://github.com/user-attachments/assets/cc8109a3-6d56-40bb-8cc7-09f6c59e0dd8" /> I realized there's probably a typo/logic error/imprecision: the `c@1.9.0` is mentioned nowhere else. I assume `c@1.9.9` was meant, because it's listed in the dependency graph above. but I have no clue about the inner workings of `npm-dedupe`, so I might be wrong here. --- alternative solution: noting `c@1.9.x`, but not using a range and explicitly matching the listed version above inherits more clarity, at least in my mind ## References <!-- Examples: Related to #0 Depends on #0 Blocked by #0 Fixes #0 Closes #0 --> - https://docs.npmjs.com/cli/v11/commands/npm-dedupe
Also updated diff in dev deps
…riables (#9385) npm sets two additional environment variables `npm_old_version` and `npm_new_version` when running the `preversion`, `version`, `postversion` scripts, but these aren’t documented anywhere. Document the variables in the ‘Scripts’ docs, and cross-reference them from the documentation for the version command (and the libnpmversion readme). I've tried to match the existing formatting conventions for each document. Please let me know if anything needs to change.
…9372) Fixes #9142, Fixes #9184 When \`npm config edit\` or \`npm edit\` opens an interactive editor, the progress spinner keeps running and writes ANSI control codes into the buffer, garbling the display. Neither command called \`input.start()\` before opening the editor, though \`help.js\` and \`open-url.js\` already handle this correctly. Wrapping both editor spawns in \`input.start()\` lets the spinner step aside while the editor has control of the terminal, and closes both issues at once. Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
BREAKING CHANGE: unknown configs in .npmrc, unknown CLI flags, abbreviated flags, and single-hyphen multi-char shorthands now throw instead of warning. Closes npm/statusboard#1084. Unknown configs are now hard errors instead of warnings: - Unknown keys in `.npmrc` (project/user/global/builtin), aggregated across files - Unknown CLI flags (`--bogus`) - Abbreviated flags (`--dry` for `--dry-run`) - Single-hyphen multi-char flags (`-longflag`) Env (`npm_config_*`) and `publishConfig` unknowns still warn. `config`, `help`, `doctor`, `completion`, and `version` opt out via `static skipConfigValidation = true` so `npm config fix` and friends keep working when `.npmrc` is broken. ### Notable breaks - Legacy top-level auth keys (`email`, `_authToken`, `_password`, `username`, `certfile`, `keyfile`) must be in scoped/nerfdart form. Run `npm config fix` to migrate. - `-j` no longer expands to `--json`. Use `--json`.
BREAKING CHANGE: root \`preinstall\` now runs before dependencies are installed.
## Problem The `generateFlagsTable` function in `docs/lib/index.js` sanitizes `description` for newlines but does not do the same for `defaultVal` or `typeVal`. Some config definitions (like `--access`) have multi-line `defaultDescription` values, which breaks the markdown table — all subsequent columns/rows get collapsed into a single garbled line. This is visible on the live docs: https://docs.npmjs.com/cli/v11/commands/npm-stage ## Fix Added `.replace(/\n/g, ' ').trim()` to both `defaultVal` and `typeVal` in `generateFlagsTable`, matching the existing sanitization already applied to `desc`. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Implements Phase 1 of [npm/rfcs#868](npm/rfcs#868), which makes dependency install scripts opt-in. **Install behaviour is unchanged.** Scripts still run as they always have. The only Phase 1 user-visible change is one advisory block at the end of `npm install` listing packages whose install scripts haven't been reviewed via the new `allowScripts` field in `package.json`. A future release will turn that advisory into an actual block. ### What landed - `allowScripts` field in `package.json`, read at install time - Three new configs: `allow-scripts`, `strict-script-builds`, `dangerously-allow-all-scripts`. The latter two are no-ops in this release. They're registered so projects can pin them in tooling ahead of the release that flips the default. - `npm approve-scripts` and `npm deny-scripts` commands, with the RFC's asymmetric pin rule (approves can pin, denies are always name-only) - Advisory warning during `npm install`, `ci`, `update`, and `rebuild`. `npm exec` / `npx` consult only the user/global `.npmrc` layer per the RFC, with the policy threaded through libnpmexec for Phase 2 enforcement. - Identity matcher in `@npmcli/arborist` covering registry, git, file, and remote tarballs. Registry identity is derived from the lockfile's resolved URL (via `versionFromTgz`), never from `node.packageName` or `node.version`. Those getters read the installed tarball's `package.json` and can be forged. - Aliases match against the underlying registered package, not the alias name. `trusted@npm:naughty@1.0.0` is approved by writing `naughty`, not `trusted`. Holds even under `omitLockfileRegistryResolved`, where the install location alone (`node_modules/trusted`) would be misleading. The underlying name is derived from the incoming edge's alias `subSpec`. - Bundled deps with install scripts are flagged as unreviewed and filtered out of `npm approve-scripts --all` and positional matches. Per RFC they cannot be allowlisted in Phase 1. - Warning when a non-root workspace declares its own `allowScripts` ### What's deliberately deferred - Actual blocking. The matcher exists and the policy is threaded through to arborist, but `arb.rebuild()`'s build set still runs everything. Phase 2 will gate `#addToBuildSet` on the matcher. - A safe allowlist syntax for bundled deps. The RFC notes a candidate `parent@1.2.3 > bundled-name` form for a follow-up. Refs: npm/rfcs#868
## Summary Adds `private` as a valid value for `--access` in `npm publish`, as an alias for `restricted`. ## Motivation The `--access` flag on `npm publish` currently accepts `restricted` and `public`. However, in everyday usage, the npm community colloquially refers to non-public packages as "private packages" — not "restricted packages." The npm website, the npm registry, and `npm access` all use the term "private" to describe these packages. ### `npm publish --access` vs `npm access` These are two different commands that deal with package visibility in different ways: - **`npm publish --access=<public|restricted>`** sets the visibility of a package **at publish time**. This is only relevant for scoped packages, where the default for new packages is `public`. - **`npm access set status=<public|private>`** changes the visibility of an **already published** package. Notably, `npm access` already uses `private` (not `restricted`) as its term for non-public packages. This inconsistency means that a user who runs `npm access set status=private` might naturally try `npm publish --access=private` and get an error. Since everyone already calls them "private packages," the CLI should accept that term too. This PR resolves that by accepting `private` as a synonym for `restricted` during publish. ## Changes - Added `private` to the valid values for the `access` config definition - The `flatten` function maps `private` → `restricted` so the registry always receives `restricted` - Updated documentation to note that `private` is an alias for `restricted` - Added tests for the `--access=private` flow --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
## Summary - stop Arborist from saving `node_modules/.package-lock.json` during dry-run reification - add a regression that keeps both `package-lock.json` and the hidden lockfile unchanged after `update: true, dryRun: true` This addresses the dry-run lockfile mutation part of #9187. The JSON output behavior is separate and already has #8567 open. ## Testing - `../../node_modules/.bin/tap --no-coverage --no-check-coverage test/arborist/reify.js -g 'dry-run update does not save lockfiles'` - `../../node_modules/.bin/tap --no-coverage --no-check-coverage test/arborist/reify.js -g 'dry run, do not get anything wet|save complete lockfile on update-all'` - `../../node_modules/.bin/eslint lib/arborist/reify.js test/arborist/reify.js` - `git diff --check` Co-authored-by: Puneet Dixit <236133619+puneetdixit200@users.noreply.github.com>
…es (#9399) In continuation of our exploration of using `install-strategy=linked` in the [Gutenberg monorepo](WordPress/gutenberg#75814), which powers the WordPress Block Editor. ## Summary In `install-strategy=linked`, every workspace not listed in the root `package.json`'s deps was getting a self-symlink inside its own `node_modules/` (e.g. `packages/test/node_modules/@namespace/test -> ..`). The workspace did not declare itself as a dependency; the link was a side effect of #9076 parking the workspace `IsolatedLink` off-root. pnpm does not create such a self-link — packages that need to self-resolve by name are expected to use Node's [`exports`-based self-referencing](https://nodejs.org/api/packages.html#self-referencing-a-package-using-its-name). ## Fix Keep the workspace `IsolatedLink` in the tree (so `--workspace` filters resolve undeclared workspaces and install scripts still run via the diff's `unchanged`-link path), but mark it `isUndeclaredWorkspaceLink = true` and treat it as tree-only: - `#extractOrLink` returns early for these links, so no symlink is materialized on disk. - `#cleanOrphanedStoreEntries` excludes them from the valid set, so any stale self-link from an older npm version is swept on the next install. - The link is no longer added to `workspace.children`. The only behavior change is that `require('<self-name>')` from inside an undeclared workspace without an `exports` field no longer resolves. This matches pnpm and the strict-isolation intent of #9076. Cross-workspace dep links, declared-workspace root symlinks, and workspace `postinstall` execution are unaffected. ## References Fixes #9398 Related to #9076
The purpose of this is to allow users to specify files that should never be published that are not project-specific, and should remain on their local machine and NOT committed to every project they happen to work with. This could include IDE files (nobody else should know or care which IDE i'm using), LLM output (.claude directories, things like that), anything that is unique to me, my environment, or my machine, that i never want published. The intention is for this global file to be configured in a user's npmrc, and then that separate file (`~/.npmignore`, for example, like how most people's global gitignore is set to `~/.gitignore`) is respected. Whether a package is using `files`, or `.npmignore` (or neither), the global npmignore is respected: with `files`, anything listed is published as normal; with `.npmignore` or neither, anything listed (except things npm _always_ publishes like package.json and the readme etc) will be removed from the packed file list.
…llution Sanitize __proto__, constructor, and prototype keys in the setKeys function to prevent prototype pollution via npm pkg set. Previously, passing __proto__.scripts.postinstall as a key would pollute Object.prototype, causing @npmcli/package-json to write inherited properties to disk and enabling RCE on next npm install. Fixes GHSA-jjm5-4238-9vmw Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Closes #9414. BREAKING CHANGE: `opts.access` now defaults to `null` instead of `'public'`. With `null`, libnpmpublish no longer sets an explicit access level in the publish payload, so new scoped packages are created as `restricted` (registry default) and republishes preserve the existing access level. Callers that want to force public access must now pass `access: 'public'` explicitly.
…stead of a sentinel
…installed signatures
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
19 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.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )