[pull] latest from npm:latest#165
Merged
Merged
Conversation
## 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.
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
5 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] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )