Repository navigation
G - #2073
Open
americanbum wants to merge 46 commits into
Open
G#2073americanbum wants to merge 46 commits into
americanbum wants to merge 46 commits into
Conversation
Bumps: - shell-quote from 4.7.8 to 4.7.9 via the lockfile. - handlebars from 1.8.2 to 1.10.0 via the lockfile. - tar, yaml, sigstore, socket.io-parser, picomatch, flatted, engine.io, axios, brace-expansion, @xmldom/xmldom, @babel/plugin-transform-modules-systemjs, @babel/core, joi, multer, svgo via the lockfile. - engine.io-client, socket.io-adapter via the lockfile to resolve ws vulnerabilities. - @actions/http-client via the lockfile to resolve high undici vulnerabilities. - socks via the lockfile to resolve ip-address vulnerabilities
<!-- What / Why --> <!-- Describe the request in detail. What it does and why it's being changed. --> ## References <!-- Examples: Related to #0 Depends on #0 Blocked by #0 Fixes #0 Closes #0 -->
…g august 2026 (npm#2006) ## Summary Starting early August 2026, Granular Access Tokens with **Bypass 2FA** enabled will no longer be permitted to perform account-identity or account-governance actions. Bypass-2FA tokens remain valid for publishing (for now) Account-identity actions clarified across the docs: - Change email or password - Modify or disable 2FA configuration - Create, escalate, or manage access tokens - Add or remove maintainers / other package-governance changes ## Files updated - `content/integrations/integrating-npm-with-external-services/about-access-tokens.mdx` — added an "Account-identity actions require an interactive 2FA challenge" section and refined the Bypass 2FA description. - `content/integrations/integrating-npm-with-external-services/creating-and-viewing-access-tokens.mdx` — clarified the Bypass 2FA checkbox scope during token creation and linked to the new section. - `content/packages-and-modules/securing-your-code/requiring-2fa-for-package-publishing-and-settings-modification.mdx` — narrowed the "bypass 2FA is enabled" bullet to package write actions and added a bullet for account-identity actions. - `content/getting-started/setting-up-your-npm-user-account/about-two-factor-authentication.mdx` — noted in the callout that account-identity actions cannot be performed with a bypass-2FA token. ## Notes - Wording aligns with the epic's "raise the floor, ease the path" framing and points users toward [trusted publishing](https://docs.npmjs.com/trusted-publishers) for CI/CD as a migration path. - No changes to nav or redirects were needed. --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> Copilot-Session: 17ac1732-86bf-4b6f-a698-70850d2b7b27
…ltiple OIDC configurations (npm#2034) This PR updates the trusted publishing docs to cover the new multiple trusted publishers behavior while keeping the previous single trusted publisher instructions available. Readers can now pick between "Single trusted publisher" and "Multiple trusted publishers" from a dropdown at the top of the Configuring section, and the whole page updates to match the selected setup. This lets us document both the current and previous behavior on one page without maintaining two separate files. To support this, a small `TrustedPublisherSwitcher` component (with `TrustedPublisherOption` children) was added to the MDX components and registered so it can be used in content. The switcher shares its selection across the page, so one control drives all the content. Content changes in the multiple-publisher version include: - A package can have up to 10 trusted publishers at the same time, so you can publish from different providers or workflows. - Existing connections can't be edited. To change the provider or required fields, delete the connection and create a new one. - The Allowed actions field now notes that npm stage publish is always allowed, with the option to also allow direct publishing with npm publish. - Updated the Managing configurations and Limitations sections to match the new behavior. The single-publisher version keeps the original instructions for anyone still on that setup.
## Summary Documents the temporary 72-hour security hold npm applies when a user logs in with a recovery code. The hold is non-rolling, cannot be lifted early, and expires automatically without any action from the user. Account behavior during the security hold is clarified across the docs: - Users can log in, browse and install packages, change their password, and add a new 2FA method. - Publishing, access-token creation, and security-sensitive account, package, organization, team, billing, and 2FA changes are temporarily blocked. - Users are directed to contact npm Support immediately if they did not use the recovery code, because their account may have been compromised. ## Files updated - `content/getting-started/setting-up-your-npm-user-account/recovering-your-2fa-enabled-account.mdx` — added the security-hold behavior before the recovery instructions, removed the unavailable option to disable 2FA during the hold, and updated the recovery-code screenshot. - `content/getting-started/setting-up-your-npm-user-account/configuring-two-factor-authentication.mdx` — added a warning that using a recovery code triggers the 72-hour security hold. - `static/getting-started/setting-up-your-npm-user-account/use-a-recovery-code.png` — added an updated screenshot of the recovery-code prompt and replaced the previous image.
## What Adds public documentation for the new **"Read and write (stage only)"** granular access token publish policy. Part of github/npm#15530 (Phase 1 — safer stage-capable GAT). Closes github/npm#15610. ## Changes **`about-access-tokens.mdx`** — new `### About stage-only tokens` section covering: - What it is / why it exists (safer automation on-ramp). - Capabilities **and** limitations: **can** stage (`npm stage publish`), deprecate, move dist-tags, unpublish; **cannot** directly publish a new version (fails with `E_STAGE_REQUIRED`). - Promotion flow: `npm stage publish` → maintainer with 2FA runs `npm stage approve <stage-id> --otp <code>`. - Jan 2027 direct-publish deprecation. - A `<Note>` explicitly stating this is **not** a general-purpose security boundary (avoids overstating security, per the issue). **`creating-and-viewing-access-tokens.mdx`** — updates the now-live **Packages and scopes** permission options to match the production UI (wubwub #3762, deployed at 100%): **Read and write (publish and stage)** / **Read and write (stage only)**. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 0f2e357f-6da8-4978-a637-f14539820093
## Summary Clarifies that staged publishing can soon be used to **create brand-new packages**, not just stage new versions of packages that already exist on the registry. ## Changes - `content/packages-and-modules/securing-your-code/staged-publishing.mdx` — updated the Prerequisites bullet to reflect that a package can be brand-new or already published. ## Companion PR The `npm stage` CLI reference pages (`content/cli/v11` and `v12`) carry the same "Package must exist" prerequisite, but those files are auto-generated from the [`npm/cli`](https://github.com/npm/cli) repo (`docs/lib/content/commands/npm-stage.md`) via the `update-cli` workflow. The matching fix is in npm/cli#10017 so the correction isn't overwritten on the next sync. --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Co-authored-by: Karen Li <karenjli@github.com> Co-authored-by: Karen Li <47998177+karenjli@users.noreply.github.com>
<!-- What / Why --> <!-- Describe the request in detail. What it does and why it's being changed. --> Documents the expiry behavior for newly created Trusted Publisher configurations. A new configuration must complete its first successful publish within 2 days of creation. If it is not validated within that period, it expires and can no longer be used or edited. Users must delete the expired configuration, create a new one, and complete the first publish within 2 days. updates - https://docs.npmjs.com/trusted-publishers <img width="879" height="289" alt="Screenshot 2026-09-21 at 4 46 13 PM" src="https://github.com/user-attachments/assets/0ab2050e-6bc0-4650-9483-5b81e3faabcb" /> ## References <!-- Examples: Related to #0 Depends on #0 Blocked by #0 Fixes #0 Closes #0 -->
…ries (npm#2058) <!-- What / Why --> - Upgrades transitive dependencies `handlebars, proxy-addr, shell-quote` to solve critical advisories in lockfile.
… mobile search (npm#2065) ## Summary Accessibility fixes for the docs site's page title, mobile navigation drawer, CLI version menu, navigation lists, and mobile search results. ## Changes ### Page title missing from `document.title` (`gatsby-browser.js`) To prevent React 19 from hoisting metadata tags, Gatsby renders the `Head` export inside an `<svg>`. This creates the `<title>` and `<meta>` elements in the SVG namespace, and Gatsby then copies them into `<head>` in place of the server-rendered tags. Browsers and assistive technology ignore an SVG `<title>`, so `document.title` was an empty string on every page once the client-side code loaded. An `onClientEntry` hook now adds a `MutationObserver` on `<head>`. It recreates any non-HTML-namespaced `[data-gatsby-head]` node as an HTML element with the same attributes and content. This works the same way as Gatsby's own handling of `<script>` tags. `document.title` is now correct on initial load and after client-side navigation, including navigation from search results. ### Mobile nav drawer contrast (`nav-drawer.module.css`) When the drawer moved from `sx` props to CSS modules, its background was hardcoded to `#333333`. The drawer content is still rendered inside `LightTheme`, so the nav items use the light theme's dark text, which gave roughly 1.2:1 contrast. The drawer body now uses `--bgColor-default` / `--fgColor-default`, matching the original `canvas.default` / `fg.default` theme values. ### CLI version menu link contrast (`variant-select.js`, `variant-select.module.css`) Version menu items were rendered with the Primer link accent color (`#0969da`). On the selected item's background this is 4.46:1, below the 4.5:1 minimum. The menu links now use `--fgColor-default`, like other action menu items. ### Mobile search results not fully visible (`search.module.css`) Primer's `ThemeProvider` wraps `LightTheme` content in a `<div data-color-mode>`. That wrapper became the flex item inside the mobile search overlay, so the results list grew to its full content height instead of shrinking and scrolling. On short viewports (for example 320 × 256 px or at 200% zoom), most results were off-screen. The wrapper is now a shrinkable flex column, so the results panel fits the remaining viewport height and scrolls. ### Console warnings (`root.js`, `page.js`, `table-of-contents.js`) - Gatsby applies `wrapRootElement` to the `Head` export as well as to pages. Primer's `ThemeProvider` renders a `<div data-color-mode>`, so a `<div>` ended up inside `Head`, causing the "`<div>` is not a valid head element" warning. `ThemeProvider` now lives in `wrapPageElement`, which Gatsby does not apply to `Head`. `MDXProvider` stays in `wrapRootElement`. - The mobile table of contents button passed `leadingIcon`, which Primer's `Button` doesn't support. React warned about an unknown DOM prop and the open/closed chevron never rendered. It now uses `leadingVisual`, so the chevron shows. ### CLI version menu group and list semantics (`variant-select.js`, `variant-select.module.css`) Each version entry rendered a `role="menuitem"` `<li>` with a separate `<a>` inside it, and keyboard focus moved to that inner link. Screen readers in focus mode announced only "Version x, link". They didn't announce the "Current"/"Legacy" group or the item's position in the menu. The entries now use `ActionList.LinkItem` with our Gatsby-aware link as the `as` component. The focused element is now the `<a role="menuitem">` inside its labelled `role="group"`, so the group name and position are announced. Client-side version switching, closing the menu and returning focus to the menu button work as before. This also stops `state="[object Object]"` from being rendered as a DOM attribute on the menu items. ### Position information for navigation lists (`nav-items.js`, `nav-hierarchy.js`) Sidebar navigation links and the page-level navigation hierarchy lists now include their position in the accessible name (for example, "npm access, 2 of 74"). This matches the table of contents and search results. Expandable sidebar items keep their existing name, because Primer's `NavList` uses that name to label the expanded sub-list. ## Testing - Verified locally with `gatsby develop` in a browser: - `document.title` is correct on initial load and after navigating through search and the sidebar. No SVG-namespaced nodes remain in `<head>`. - Nav drawer items render dark text on a light background at 640 px width. - Version menu links render `#1f2328` on the selected item background. - At 320 × 256 px, the search results panel is constrained to the viewport and all 12 results are reachable by scrolling and arrow keys. - No "invalid head element" or unknown `leadingIcon` prop messages in the browser console. The mobile table of contents button shows its chevron. - In the CLI version menu, focus moves between `role="menuitem"` links inside the "Current"/"Legacy" groups. Selecting a version with Enter or a click navigates to that version, closes the menu and returns focus to the menu button. - Sidebar links (for example the CLI commands list) and the page navigation lists on section index pages include "N of M" in their accessible names. - `npm test` and `npm run lint` pass. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
## Summary
The CLI docs build stops marking any CLI version as the default
("latest") when npm publishes a new patch before moving the `latest`
dist-tag to it. This PR fixes the build logic and makes the version menu
handle a missing latest version.
## Problem
`cli/lib/build.js` marked a release as the default only when the newest
version in that major **exactly** matched npm's `latest` dist-tag:
```js
default: semver.eq(version, pack.latest)
```
npm `12.2.1` is published under the `next-12` tag, while `latest` still
points to `12.2.0`. The build picks `12.2.1` as the newest v12 release,
which isn't equal to `12.2.0`, so no release is marked default and v12
falls through to `type: legacy`. The last automated CLI docs update
wrote that result to `main`, which has two effects:
- **Version menu:** `nav.yml` has no `latest` variant, so the "Select
CLI Version" menu renders an empty, focusable "Current" item. It is
focused first when the menu opens, and screen readers announce a blank
menu item.
- **Unversioned redirects:** the default version's pages carry the
unversioned `redirect_from` entries (for example
`/cli/commands/npm-install`). With v12 no longer default, those entries
were removed from the v12 pages, so a clean build no longer produces
those redirects.
The same drop-and-restore of `type: latest` has happened in earlier
automated updates. It recurs whenever a patch is published before
`latest` is moved.
## Changes
- **`cli/lib/build.js`:** the default release is now the one whose
**major** matches the `latest` dist-tag:
```js
default: semver.major(version) === semver.major(pack.latest)
```
- **`cli/test/index.js`:** new test for a newer patch (`9.0.1`)
published while `latest` is still `9.0.0`. It fails with the old logic
(`legacy`) and passes with the fix.
- **`src/components/variant-select.js`:** the "Current" group and each
item in it are only rendered when that version exists, so a missing
latest version can no longer produce an empty menu item.
- **`content/nav.yml`:** v12 is set back to `default: true` / `type:
latest`. This is the exact `nav.yml` output of the fixed build against
the live registry, so the version menu shows v12 under "Current" as
"(Latest)" again.
- **`src/components/variant-select.js` (focus after choosing a
version):** choosing a version closed the menu and returned focus to the
menu button immediately, while the button still showed the previous
version and was still expanded. The button then updated without being
announced, so NVDA read the old version (for example "Version 12.2.1
(Latest), menu button, expanded" after choosing 11.21.1). The menu now
stays open until the selected version has loaded, then closes and moves
focus to the button once, so it is announced with the new version and as
collapsed. Escape, Tab, choosing the version you're already on, and
modifier-clicks (open in a new tab) behave as before.
The generated v12 pages (`content/cli/v12/**`) are not changed here. The
scheduled "Update CLI" workflow regenerates them with the fixed build on
its next v12 update, which restores the unversioned `redirect_from`
entries.
## Testing
- CLI build tests (`node --test ./test/index.js ./test/transform.js`):
10/10 pass. The new test fails without the `build.js` change.
- Running the fixed build against the live registry produces v12
`default: true` / `type: latest` and restores the unversioned
`redirect_from` entries on the v12 pages, with no other content changes.
- `npm run build -w cli -- --check-only` passes.
- `npm test` (jest) and `npm run lint` pass.
- `content/nav.yml` is identical to the `nav.yml` produced by the fixed
build.
- Focus after choosing a version, recorded at the moment the menu button
receives focus:
- With Enter and with a mouse click, the button receives focus once,
already showing the new version ("Version 11.21.1 (Legacy)", "Version
9.9.4 (Legacy)") with `aria-expanded="false"`.
- Escape closes the menu and returns focus to the collapsed button. Tab
closes the menu and moves on.
- Choosing the version you're already on closes the menu and returns
focus to the button. Cmd/Ctrl+click opens that version in a new tab and
leaves the current page unchanged.
- The browser Back button between versions still focuses the button with
the right version. Navigating within the same version doesn't move focus
to it.
- Verified locally with `gatsby develop`: the version menu shows
"Version 12.2.1" under "Current" and the other versions under "Legacy",
with no empty items. Opening the menu focuses "Version 12.2.1"
("Current", 1 of 1). Selecting it opens `/cli/v12/using-npm` labelled
"(Latest)" and returns focus to the menu button. With v12 set to
`legacy`, the menu shows no "Current" group and no empty item.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This branch was successfully deployed
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.
References