Commit a4cd2d5
authored
chore(deps): update npm packages (#721)
This PR contains the following updates:
| Package | Change |
[Age](https://docs.renovatebot.com/merge-confidence/) |
[Adoption](https://docs.renovatebot.com/merge-confidence/) |
[Passing](https://docs.renovatebot.com/merge-confidence/) |
[Confidence](https://docs.renovatebot.com/merge-confidence/) |
|---|---|---|---|---|---|
| [@vitest/coverage-v8](https://vitest.dev/guide/coverage)
([source](https://redirect.github.com/vitest-dev/vitest/tree/HEAD/packages/coverage-v8))
| [`4.1.5` →
`4.1.6`](https://renovatebot.com/diffs/npm/@vitest%2fcoverage-v8/4.1.5/4.1.6)
|

|

|

|

|
| [pnpm](https://pnpm.io)
([source](https://redirect.github.com/pnpm/pnpm/tree/HEAD/pnpm)) |
[`11.0.4` →
`11.1.2`](https://renovatebot.com/diffs/npm/pnpm/11.0.4/11.1.2) |

|

|

|

|
|
[typescript-eslint](https://typescript-eslint.io/packages/typescript-eslint)
([source](https://redirect.github.com/typescript-eslint/typescript-eslint/tree/HEAD/packages/typescript-eslint))
| [`8.59.2` →
`8.59.3`](https://renovatebot.com/diffs/npm/typescript-eslint/8.59.2/8.59.3)
|

|

|

|

|
---
### Release Notes
<details>
<summary>vitest-dev/vitest (@​vitest/coverage-v8)</summary>
###
[`v4.1.6`](https://redirect.github.com/vitest-dev/vitest/releases/tag/v4.1.6)
[Compare
Source](https://redirect.github.com/vitest-dev/vitest/compare/v4.1.5...v4.1.6)
##### 🐞 Bug Fixes
- **browser**: Provide project reference in
`ToMatchScreenshotResolvePath` - by
[@​macarie](https://redirect.github.com/macarie) and
[@​sheremet-va](https://redirect.github.com/sheremet-va) in
[#​10138](https://redirect.github.com/vitest-dev/vitest/issues/10138)
[<samp>(31882)</samp>](https://redirect.github.com/vitest-dev/vitest/commit/31882607c)
- Global `sequence.concurrent: true` with top-level `test(..., {
concurrent: false })` + depreacte `sequential` test API and options -
by [@​hi-ogawa](https://redirect.github.com/hi-ogawa), **Codex**
and [@​sheremet-va](https://redirect.github.com/sheremet-va) in
[#​10196](https://redirect.github.com/vitest-dev/vitest/issues/10196)
[<samp>(2847d)</samp>](https://redirect.github.com/vitest-dev/vitest/commit/2847dfa2a)
- **browser**: Simplify orchestrator otel carrier - by
[@​hi-ogawa](https://redirect.github.com/hi-ogawa) in
[#​10285](https://redirect.github.com/vitest-dev/vitest/issues/10285)
[<samp>(18af9)</samp>](https://redirect.github.com/vitest-dev/vitest/commit/18af98cee)
##### 🏎 Performance
- Stringify diff objects only once - by
[@​sheremet-va](https://redirect.github.com/sheremet-va) in
[#​10276](https://redirect.github.com/vitest-dev/vitest/issues/10276)
[<samp>(9f7b1)</samp>](https://redirect.github.com/vitest-dev/vitest/commit/9f7b1528c)
##### [View changes on
GitHub](https://redirect.github.com/vitest-dev/vitest/compare/v4.1.5...v4.1.6)
</details>
<details>
<summary>pnpm/pnpm (pnpm)</summary>
###
[`v11.1.2`](https://redirect.github.com/pnpm/pnpm/blob/HEAD/pnpm/CHANGELOG.md#1112)
[Compare
Source](https://redirect.github.com/pnpm/pnpm/compare/v11.1.1...v11.1.2)
##### Patch Changes
- `convertEnginesRuntimeToDependencies`: switch the runtime-dependency
write to `Object.defineProperty` so the CodeQL
`js/prototype-polluting-assignment` rule treats the assignment as safe
regardless of the property name (follow-up to
[#​11609](https://redirect.github.com/pnpm/pnpm/pull/11609)).
- Address CodeQL static-analysis findings: guard manifest dependency
writes against prototype-polluting keys (`__proto__`, `constructor`,
`prototype`), and replace a potentially super-linear semver-detection
regex in registry 404 hints with an O(n) parser.
- Strip `sec-fetch-*` headers from outgoing HTTP requests. These headers
are automatically added by undici's `fetch()` implementation per the
Fetch spec but cause Azure DevOps Artifacts to return HTTP 400 for
uncached upstream packages, as ADO interprets them as browser requests
[#​11572](https://redirect.github.com/pnpm/pnpm/issues/11572).
- Fix `minimumReleaseAge` handling for cached abbreviated metadata.
The version-spec cache fast path no longer rethrows
`ERR_PNPM_MISSING_TIME` under `strictPublishedByCheck`; it now falls
through to the registry-fetch path, consistent with the adjacent
mtime-gated cache block.
When the registry returns 304 Not Modified for a package whose cached
metadata is abbreviated (no per-version `time`), pnpm now re-fetches
with `fullMetadata: true` if `minimumReleaseAge` is active and the
package was modified after the cutoff. The upgraded metadata is
persisted to disk so subsequent installs don't repeat the fetch.
Previously the abbreviated meta was used as-is and the maturity check
fell back to its warn-and-skip path, silently bypassing the quarantine
and emitting a misleading "metadata is missing the time field" warning.
Closes
[#​11619](https://redirect.github.com/pnpm/pnpm/issues/11619).
- Fix `pnpm upgrade --interactive --latest -r` not respecting named
catalog groups. Previously, upgrading a dependency using a named catalog
(e.g. `"catalog:foo"`) would incorrectly rewrite `package.json` to
`"catalog:"` and place the updated version in the default catalog
instead of the named one
[#​10115](https://redirect.github.com/pnpm/pnpm/issues/10115).
- Fixed `optimisticRepeatInstall` skipping `pnpm-lock.yaml` merge
conflict resolution when the existing `node_modules` state appears up to
date.
- Fix `minimumReleaseAge` / `resolutionMode: time-based` installs
failing on lockfiles whose `time:` block is missing entries. The
npm-resolver's peek-from-store fast path now surfaces `publishedAt` from
the lockfile rather than discarding it, and falls through to a registry
metadata fetch when the time-based cutoff can't be computed from the
data on hand.
###
[`v11.1.1`](https://redirect.github.com/pnpm/pnpm/blob/HEAD/pnpm/CHANGELOG.md#1111)
[Compare
Source](https://redirect.github.com/pnpm/pnpm/compare/v11.1.0...v11.1.1)
##### Patch Changes
- Skip installability validation when scanning workspace projects in
`checkDepsStatus` (run by `verifyDepsBeforeRun`). Previously the status
check called `findWorkspaceProjects`, which validates each project's
`engines` and `os`/`cpu`/`libc` and warns about useless fields in
non-root manifests — work that the install pipeline already performs.
With no `nodeVersion` threaded through, the engine check also fell back
to the system Node from `PATH` and emitted spurious "Unsupported engine"
warnings before scripts ran. Status-only callers now use
`findWorkspaceProjectsNoCheck`; install paths continue to validate.
- Fixed `pnpm add <alias>:@​scope/pkg` for [named
registries](https://redirect.github.com/pnpm/pnpm/pull/11324). The local
resolver was claiming any specifier containing `/` as a local directory,
so `pnpm add bit:@​teambit/bit` (with `bit` configured under
`namedRegistries`) installed a bogus link to `bit:@​teambit/bit/`
instead of resolving from the configured registry. The local resolver
now runs after the named-registry resolver in the resolution chain.
- Updated `@zkochan/cmd-shim` to 9.0.3. The sh shim it writes for `.cmd`
/ `.bat` targets now escapes the `/C` switch as `//C`, so it survives
the path translation Git Bash applies when launching `cmd.exe`. Without
this, a bare `/C` was rewritten to `C:\` before reaching cmd.exe — the
switch was dropped, cmd started interactively, and the calling script
saw the cmd banner instead of the wrapped command's output. Affects any
cmd-shim-wrapped batch script invoked from Git Bash / MSYS / Cygwin on
Windows. See
[pnpm/cmd-shim#55](https://redirect.github.com/pnpm/cmd-shim/pull/55).
###
[`v11.1.0`](https://redirect.github.com/pnpm/pnpm/blob/HEAD/pnpm/CHANGELOG.md#1110)
[Compare
Source](https://redirect.github.com/pnpm/pnpm/compare/v11.0.9...v11.1.0)
##### Minor Changes
- Added `pnpm audit signatures` to verify ECDSA registry signatures for
installed packages against keys from `/-/npm/v1/keys`
[#​7909](https://redirect.github.com/pnpm/pnpm/issues/7909).
Scoped registries are respected, and registries without signing keys are
skipped.
- Added support for installing packages from the [GitHub Packages npm
registry](https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-npm-registry)
via a built-in `gh:` prefix (e.g. `pnpm add gh:@​acme/private`),
and, more broadly, for arbitrary named registries in the style of [vlt's
named-registry aliases](https://docs.vlt.sh/cli/registries).
Authentication is picked up from the existing per-URL `.npmrc` entries
(e.g. `//npm.pkg.github.com/:_authToken=...`), so no separate auth
mechanism is required.
Additional aliases — or an override for the built-in `gh` alias, for
GitHub Enterprise Server — can be configured under `namedRegistries` in
`pnpm-workspace.yaml`:
```yaml
namedRegistries:
gh: https://npm.pkg.github.example.com/
work: https://npm.work.example.com/
```
With this, `work:@​corp/lib@^2.0.0` resolves against
`https://npm.work.example.com/`.
[#​8941](https://redirect.github.com/pnpm/pnpm/issues/8941).
- Allow setting sbom spec version using `--sbom-spec-version`
[#​11389](https://redirect.github.com/pnpm/pnpm/pull/11389).
- Add `--no-runtime` flag (config: `runtime=false`) to skip installing
runtime entries (e.g. Node.js downloaded via `devEngines.runtime`)
without modifying the lockfile. The lockfile keeps the runtime entry so
frozen-lockfile validation still passes; only the runtime fetch and
`.bin` linking are skipped. Useful in CI matrices where the runtime is
provisioned externally (e.g. via `pnpm runtime -g set node <version>`)
before `pnpm install` runs.
- Added the `pnpm bugs` command that opens a package's bug tracker URL
in the browser. With no arguments, it reads the current project's
`package.json`; with one or more package names, it fetches each
package's metadata from the registry and opens its bug tracker. Falls
back to `<repository>/issues` when the `bugs` field is missing
[#​11279](https://redirect.github.com/pnpm/pnpm/pull/11279).
- Added `pnpm owner` command to manage package owners on the registry.
##### Patch Changes
- Added "published X ago by Y" information to the `pnpm view` command
output, similar to `npm view`. This is useful when comparing against
`minimumReleaseAge`.
For example, `pnpm view pnpm` now shows:
```
published 17 hours ago by GitHub Actions
```
- `pnpm publish` now honors the configured HTTP/HTTPS proxy (including
`https_proxy`/`http_proxy`/`no_proxy` environment variables) when
polling the registry's `doneUrl` during the web-based authentication
flow. Previously the poll bypassed the proxy, causing the registry to
respond `403` from a different source IP and the login to never complete
[#​11561](https://redirect.github.com/pnpm/pnpm/issues/11561).
- `pnpm add -g` now installs each space-separated package into its own
isolated directory by default. To bundle multiple packages into the same
isolated install (so that they share dependencies and are removed
together), pass them as a comma-separated list. For example:
- `pnpm add -g foo bar` installs `foo` and `bar` as two independent
globals — removing one does not affect the other.
- `pnpm add -g foo,bar qar` bundles `foo` and `bar` into a single
isolated install while `qar` is installed on its own.
Related:
[#​11587](https://redirect.github.com/pnpm/pnpm/issues/11587).
- `pnpm runtime set <name> <version>` no longer fails in the root of a
multi-package workspace with the `ADDING_TO_ROOT` error. Installing the
workspace root is a valid target for a runtime, so the command now
bypasses that safety check.
- Fix `pnpm --version` hanging for the lifetime of the worker pool after
the version was printed. `main.ts`'s `--version` short-circuit returned
before reaching the command-handler `finally` that calls
`finishWorkers()`, so the worker pool that `switchCliVersion` had
spawned during integrity resolution stayed alive and held the Node event
loop open. The CLI entry now runs `finishWorkers()` from its own
`finally`, so every exit path tears the pool down.
Repro: `pnpm --version` in a workspace whose `devEngines.packageManager`
version already matches the running pnpm + `onFail: "download"`.
`switchCliVersion` resolves the integrity (spawning workers), finds
nothing to swap, returns. The version prints, then the process hangs.
###
[`v11.0.9`](https://redirect.github.com/pnpm/pnpm/blob/HEAD/pnpm/CHANGELOG.md#1109)
[Compare
Source](https://redirect.github.com/pnpm/pnpm/compare/v11.0.8...v11.0.9)
##### Patch Changes
- Fixed installation of GitLab-hosted dependencies. pnpm now downloads
the tarball from
`https://gitlab.com/<user>/<project>/-/archive/<sha>/<project>-<sha>.tar.gz`
instead of the GitLab API endpoint that contained an encoded slash
(`%2F`) between user and project. The encoded slash both triggered `406
Not Acceptable` responses from GitLab and produced virtual store
directory names that Node refused to import
(`ERR_INVALID_MODULE_SPECIFIER`)
[#​11533](https://redirect.github.com/pnpm/pnpm/issues/11533).
- Honor `NPM_CONFIG_USERCONFIG` (and its lowercase
`npm_config_userconfig` form) as a low-priority fallback when locating
the user-level `.npmrc`. This restores compatibility with environments
that point npm at a custom auth file via that env var — most notably
`actions/setup-node`, which writes registry credentials to
`${runner.temp}/.npmrc` and exports `NPM_CONFIG_USERCONFIG` to reference
it. Without this, GitHub Actions workflows using `actions/setup-node` to
authenticate to private registries broke after upgrading to pnpm v11.
PNPM-prefixed env vars and `npmrcAuthFile` from the global `config.yaml`
continue to take precedence
[#​11539](https://redirect.github.com/pnpm/pnpm/issues/11539).
- Fix `pnpm pack` not bundling dependencies listed in
`bundleDependencies` (or `bundledDependencies`). The npm-packlist
upgrade in pnpm 11 changed its API to require the caller to pre-populate
the dependency tree, which the wrapper was not doing —
`bundleDependencies` were silently dropped from the tarball
[#​11519](https://redirect.github.com/pnpm/pnpm/issues/11519).
- Fixed the pnpm CLI crashing with a confusing `SyntaxError: Invalid
regular expression flags` instead of printing a clear "requires Node.js
v22.13" error when launched on an unsupported Node.js version. The
Node.js version check in `bin/pnpm.mjs` was effectively dead code
because the static `import` of the bundled `dist/pnpm.mjs` was hoisted
by the ES module loader and parsed before the check could run
[#​11546](https://redirect.github.com/pnpm/pnpm/issues/11546).
- Fixed `pnpm --prefix=<dir> install` overwriting the existing
`pnpm-workspace.yaml` in `<dir>` with `set this to true or false`
placeholders. The renamed `--prefix` option (which maps to `dir`) was
not honored when locating the workspace root, so the workspace
manifest's `allowBuilds` settings were not loaded into config and got
clobbered when ignored builds were auto-populated
[#​11535](https://redirect.github.com/pnpm/pnpm/issues/11535).
- Fixed `pnpm publish --provenance` failing with a 422 from the registry
when the package version contained semver build metadata (e.g.
`1.0.0-canary.0+abc1234`). The `+<build>` segment is now stripped before
packing so that the version embedded in the tarball, the metadata sent
to the registry, and the sigstore provenance subject all agree
[#​11518](https://redirect.github.com/pnpm/pnpm/issues/11518).
###
[`v11.0.8`](https://redirect.github.com/pnpm/pnpm/blob/HEAD/pnpm/CHANGELOG.md#1108)
[Compare
Source](https://redirect.github.com/pnpm/pnpm/compare/v11.0.7...v11.0.8)
##### Patch Changes
- Restored the heuristic that preserves tarball URLs in `pnpm-lock.yaml`
when they cannot be derived from name+version+registry, even with the
default `lockfileIncludeTarballUrl: false`. Without this, `pnpm install
--frozen-lockfile` from an empty store fails with `ERR_PNPM_FETCH_404`
for packages on registries that serve tarballs from a non-standard path
— most notably GitHub Packages
(`https://npm.pkg.github.com/download/<scope>/<name>/<version>/<hash>`)
and JSR. `lockfileIncludeTarballUrl: true` continues to force the URL
into the lockfile for every package
[#​11276](https://redirect.github.com/pnpm/pnpm/issues/11276).
- Run `preversion`, `version`, and `postversion` lifecycle scripts for
`pnpm version`.
- Fixed `ERR_PNPM_BAD_TARBALL_SIZE` when a registry serves tarballs with
an end-to-end `Content-Encoding` (e.g. `gzip`). Tarballs are already
compressed, so the fetcher now requests them with `Accept-Encoding:
identity` (matching pnpm v10's effective behavior) and, as defense in
depth against misbehaving servers, no longer enforces the strict
`Content-Length` check when the response declares a `Content-Encoding` —
`Content-Length` in that case refers to the encoded payload, not the
decoded bytes the fetch implementation yields
[#​11506](https://redirect.github.com/pnpm/pnpm/issues/11506).
###
[`v11.0.7`](https://redirect.github.com/pnpm/pnpm/blob/HEAD/pnpm/CHANGELOG.md#1107)
[Compare
Source](https://redirect.github.com/pnpm/pnpm/compare/v11.0.6...v11.0.7)
##### Patch Changes
- Restore the execute bit on the `node-gyp` shims packed inside
`@pnpm/exe` (`dist/node-gyp-bin/node-gyp`,
`dist/node-gyp-bin/node-gyp.cmd`, and
`dist/node_modules/node-gyp/bin/node-gyp.js`). Without this,
`pnpm/action-setup`'s standalone path (used on runners with Node.js <
22.13) failed any install whose lifecycle script invoked `node-gyp
rebuild` with `sh: 1: node-gyp: Permission denied`
[#​11483](https://redirect.github.com/pnpm/pnpm/issues/11483).
- Fixed the `pn`, `pnpx`, and `pnx` aliases failing in Git Bash / MSYS2
on Windows when pnpm was installed via `@pnpm/exe` (or after `pnpm
self-update`)
[#​11486](https://redirect.github.com/pnpm/pnpm/issues/11486).
Running `pnpx` (or `pnx`) printed the cmd.exe banner and dropped the
user into an interactive command prompt instead of running `pnpm dlx`.
The `bin` field rewrite on Windows was pointing those aliases at `.cmd`
files; cmd-shim's Bash shim for a `.cmd` target wraps it in `exec cmd /C
...`, and MSYS2 mangles `/C` into a Windows path before cmd.exe sees it.
The aliases are now `.exe` hardlinks of the SEA binary, which detects
which name it was launched as via `process.execPath` and prepends `dlx`
for `pnpx` / `pnx`.
- Fix `pnpm install` recreating `node_modules` after `pnpm fetch`. `pnpm
fetch` records empty `hoistPattern` and `publicHoistPattern` in
`.modules.yaml`; since v11 removed the explicit-config gate, the
follow-up install treated those as a hoist-pattern change and purged the
modules directory. The fetch step now flags the modules manifest with
`virtualStoreOnly: true` so the next install skips the hoist-pattern
comparison and completes the missing post-import linking in place
[#​11488](https://redirect.github.com/pnpm/pnpm/issues/11488).
- Pin the integrity of git-hosted tarballs (codeload.github.com,
gitlab.com, bitbucket.org) in the lockfile so that subsequent installs
detect a tampered or substituted tarball and refuse to install it.
Previously the lockfile only stored the tarball URL for git
dependencies, so a compromised git host or a man-in-the-middle could
serve arbitrary code on later installs without lockfile changes.
A new `gitHosted: true` field is recorded on git-hosted tarball
resolutions in the lockfile, letting every reader/writer route them by a
single typed check instead of pattern-matching the tarball URL in each
call site. Lockfiles written by older pnpm versions are enriched on load
(URL fallback) so the field can be relied on uniformly across the
codebase.
- Allow user-level preferences in the global `config.yaml`. The
following settings can now be set in `~/.config/pnpm/config.yaml` (or
via `pnpm config set --location global`) instead of being restricted to
`pnpm-workspace.yaml`: `agent`, `globalVirtualStoreDir`,
`initPackageManager`, `initType`, `registrySupportsTimeField`,
`scriptShell`, `shellEmulator`, `sideEffectsCache`,
`sideEffectsCacheReadonly`, `stateDir`, `strictDepBuilds`,
`trustPolicy`, `trustPolicyExclude`, `trustPolicyIgnoreAfter`,
`updateNotifier`, `useStderr`, `verifyDepsBeforeRun`,
`verifyStoreIntegrity`, `virtualStoreDir`, `virtualStoreDirMaxLength`
[#​11474](https://redirect.github.com/pnpm/pnpm/issues/11474).
- Make trusted publishing (OIDC) take precedence over a configured
static `_authToken` in `pnpm publish`, mirroring the npm CLI's behavior.
When OIDC succeeds, the OIDC-derived token overrides any pre-configured
`_authToken`; when OIDC is not applicable (no CI environment, exchange
fails, registry has no trusted publisher configured), the static token
is used as a fallback. This applies on every package during recursive
publish, so each workspace package independently attempts trusted
publishing.
Additionally, the `NPM_ID_TOKEN` env var is now honored as a CI-agnostic
injection point for an OIDC ID token. Previously OIDC was only attempted
on GitHub Actions or GitLab; now any CI provider that exposes its own
OIDC mechanism (e.g. CircleCI's `CIRCLE_OIDC_TOKEN_V2`, Buildkite, etc.)
can forward its token via `NPM_ID_TOKEN` and trusted publishing will
work without pnpm needing to recognize the provider explicitly.
- `--pm-on-fail=ignore` (and other universal options like `--loglevel`,
`--reporter`) is now honored when combined with `--help` or `--version`.
Previously the CLI argument parser short-circuited those flags before
universal options were preserved, so `pnpm audit --pm-on-fail=ignore
--help` and `pnpm --pm-on-fail=ignore --version` reported the strict
packageManager mismatch instead of running the requested action
[#​11487](https://redirect.github.com/pnpm/pnpm/issues/11487).
- Fix a regression where `pnpm --recursive --filter '!<pkg>'
run/exec/test/add` would include the workspace root in the matched
projects. The workspace root is now correctly excluded by default when
only negative `--filter` arguments are provided, matching the
[documented behavior](https://pnpm.io/cli/recursive). To include the
root, pass `--include-workspace-root`
[#​11341](https://redirect.github.com/pnpm/pnpm/issues/11341).
- Restore npm-CLI-compatible `--json` stdout output for `pnpm publish`
([#​11476](https://redirect.github.com/pnpm/pnpm/issues/11476)).
pnpm 11 reimplemented publish natively
([#​10591](https://redirect.github.com/pnpm/pnpm/pull/10591)) and
inadvertently dropped the per-package JSON object that pnpm 10 emitted
transitively via the npm CLI, silently breaking downstream tooling —
most notably `nx release publish`, which parses stdout JSON to confirm
success
([nrwl/nx#35575](https://redirect.github.com/nrwl/nx/issues/35575)). On
success, the output is now:
- `pnpm publish --json` → single object `{ id, name, version, size,
unpackedSize, shasum, integrity, filename, files, entryCount, bundled
}`, mirroring `npm publish --json`.
- `pnpm publish -r --json` → array of those objects, mirroring `pnpm
pack --json`'s shape choice.
- `pnpm publish -r --report-summary` → existing
`pnpm-publish-summary.json` envelope `{ publishedPackages: [...] }` is
preserved, but each entry is upgraded to the same per-package shape
(additive — `name` and `version` are still present).
- `pnpm config get @​<scope>:registry` now reports the same URL
that `pnpm publish` and the resolvers actually use. Previously, `config
get` only consulted `.npmrc`, while `publish`/install used the merged
map that includes `pnpm-workspace.yaml`'s `registries` block — so the
two could diverge silently and a publish could go to the wrong registry
[#​11492](https://redirect.github.com/pnpm/pnpm/issues/11492).
###
[`v11.0.6`](https://redirect.github.com/pnpm/pnpm/blob/HEAD/pnpm/CHANGELOG.md#1106)
[Compare
Source](https://redirect.github.com/pnpm/pnpm/compare/v11.0.5...v11.0.6)
##### Patch Changes
- Fix `pnpm_config_npmrc_auth_file` and `pnpm_config_userconfig` env
vars not actually loading the custom `.npmrc`. The env vars were parsed
and assigned to the resolved config, but only after `loadNpmrcConfig`
had already read the default `~/.npmrc` — so the custom file path was
set but never read. The relevant env vars are now consulted before the
user-level `.npmrc` is loaded
[#​11465](https://redirect.github.com/pnpm/pnpm/issues/11465).
- Preserve the original key order in `pnpm-workspace.yaml` when updating
it. Existing keys keep their position, and new keys are inserted in
alphabetical position when the existing keys are already sorted (with a
leading `packages` key allowed) or appended at the end otherwise.
- Fixed `pnpm self-update` on installations originally set up by pnpm
v10. v10 added `PNPM_HOME` directly to PATH and wrote a `pnpm` bootstrap
shim there. v11 setup writes shims under `PNPM_HOME/bin` instead, so
when a v10 user upgrades to v11 the legacy shim at `PNPM_HOME` keeps
pointing into the old `.tools/<version>` install — `pnpm --version`
continues to report the pre-update version even though the new version
was installed under `global/v11`. Self-update now detects this layout,
refreshes the legacy shims so the upgrade actually takes effect, and
prints a hint suggesting `pnpm setup` to migrate PATH to the v11 layout.
[#​11464](https://redirect.github.com/pnpm/pnpm/issues/11464).
- Print a warning when settings that are not allowed in the global
config file (e.g. `nodeLinker`, `hoistPattern`) are present in
`config.yaml` and silently ignored. Previously these settings were
dropped without any feedback, leaving users unsure why their global
configuration had no effect. The warning suggests moving those settings
to a project-level `pnpm-workspace.yaml`, or sharing them across
projects via [config
dependencies](https://pnpm.io/11.x/config-dependencies).
- Throw a pnpm error when `overrides` has an invalid shape or contains a
non-string value.
- Validate all `readPackage` dependency map fields, including
`devDependencies`, and reject falsy non-object invalid values instead of
silently accepting them.
- Prevent crashes during `pnpm config`, `pnpm set`, and `pnpm get` by
tolerating `configDependencies` install failures. For these commands, a
failure to install `configDependencies` (for example because the
registry auth token has not been written yet) is now logged at debug
level and the command proceeds. All other commands still surface the
install error
[#​10684](https://redirect.github.com/pnpm/pnpm/issues/10684).
- Treat `allowBuilds` as an install-state input and clear previously
ignored builds when they are explicitly disallowed.
- Fixes
[#​10594](https://redirect.github.com/pnpm/pnpm/issues/10594),
catalogs not being read from the workspace when using the `catalog:`
protocol with the `pnpm dlx` / `pnpx` command, resulting in a catalog
entry not found error.
- Accept `PNPM_CONFIG_*` (uppercase) environment variables in addition
to `pnpm_config_*`. Previously, only the lowercase form was honored, so
env vars renamed per the v11 migration guide (e.g.
`PNPM_CONFIG_USERCONFIG`) silently had no effect on case-sensitive
systems like macOS and Linux
[#​11465](https://redirect.github.com/pnpm/pnpm/issues/11465).
###
[`v11.0.5`](https://redirect.github.com/pnpm/pnpm/blob/HEAD/pnpm/CHANGELOG.md#1105)
[Compare
Source](https://redirect.github.com/pnpm/pnpm/compare/v11.0.4...v11.0.5)
##### Patch Changes
- Drop the `darwin-x64` artifact from `@pnpm/exe` and from the GitHub
release page. The Node.js SEA mechanism `pnpm pack-app` uses produces a
binary that segfaults at startup on Intel Macs because of an upstream
Node.js bug
([nodejs/node#62893](https://redirect.github.com/nodejs/node/issues/62893),
tracked alongside
[#​59553](https://redirect.github.com/nodejs/node/issues/59553);
the Node.js team has [opted not to fix
it](https://redirect.github.com/nodejs/node/pull/60250) on the grounds
that x64 macOS is being phased out). Re-signing with `codesign` or
`ldid` doesn't help — the corruption is in LIEF's Mach-O surgery, before
signing.
Intel Mac users should install pnpm via `npm install -g pnpm` (uses the
system Node.js, no SEA), or stay on pnpm 10.x. `@pnpm/exe`'s preinstall
on Intel Mac now exits with a clear error pointing at these
alternatives.
Closes
[#​11423](https://redirect.github.com/pnpm/pnpm/issues/11423).
- `pnpm dlx` (and `pnpx`/`pnx`/`pnpm create`) now runs the same
interactive `approve-builds` prompt as `pnpm add -g` when the package
being launched depends on transitive packages with install scripts.
Previously, the v11 `strictDepBuilds` default made dlx fail with
`ERR_PNPM_IGNORED_BUILDS` and required users to re-run with
`--allow-build=<pkg>` for every offending dependency. dlx also now
removes the partially-populated cache directory when the install fails,
so a subsequent run starts clean instead of reusing a broken install
whose builds were silently skipped
[#​11444](https://redirect.github.com/pnpm/pnpm/issues/11444).
- [`72629fc`](https://redirect.github.com/pnpm/pnpm/commit/72629fc): Fix
`pnpm -g ls --json` and `pnpm -g ls --parseable` so they emit valid JSON
and parseable output respectively, matching pnpm 10 behavior. Since the
isolated global packages refactor in pnpm 11, the global list command
had a custom path that always printed plain text and ignored
`--json`/`--parseable`, which broke tools like `npm-check-updates` that
parse the JSON output
[#​11440](https://redirect.github.com/pnpm/pnpm/issues/11440).
`pnpm -g ls --depth=<n>` (with n > 0) now errors when more than one
isolated global install would be involved, since each install has its
own lockfile and merging their transitive trees would be incoherent.
When the request can be narrowed to a single install group, the regular
`list` flow is used and the full dependency tree is shown.
- Fixed `pnpm publish` to honor `publishConfig.registry` from
`package.json` when publishing a single package. The native publish flow
introduced in v11 was reading the registry from `.npmrc` only, ignoring
the per-package override
[#​11419](https://redirect.github.com/pnpm/pnpm/issues/11419).
- When `strictPeerDependencies` is `true`, the
`ERR_PNPM_PEER_DEP_ISSUES` error once again renders the peer dependency
issues inline using the same format as `pnpm peers check`, so users (and
CI tools like Renovate) can see what failed without running `pnpm peers
check` separately
[#​11439](https://redirect.github.com/pnpm/pnpm/issues/11439).
- The `WARN` and error code labels in pnpm's output now wrap in brackets
(`[WARN]`, `[ERR_PNPM_FOO]`). Previously the labels relied entirely on a
colored background to stand out, which meant they blended into the
surrounding text in terminals without color (e.g. when `NO_COLOR` is set
or output is piped). The brackets are painted in the same color as the
badge background, so they appear as ordinary padding in color-capable
terminals — only the no-color rendering changes.
</details>
<details>
<summary>typescript-eslint/typescript-eslint
(typescript-eslint)</summary>
###
[`v8.59.3`](https://redirect.github.com/typescript-eslint/typescript-eslint/blob/HEAD/packages/typescript-eslint/CHANGELOG.md#8593-2026-05-11)
[Compare
Source](https://redirect.github.com/typescript-eslint/typescript-eslint/compare/v8.59.2...v8.59.3)
This was a version bump only for typescript-eslint to align it with
other projects, there were no code changes.
See [GitHub
Releases](https://redirect.github.com/typescript-eslint/typescript-eslint/releases/tag/v8.59.3)
for more information.
You can read about our [versioning
strategy](https://typescript-eslint.io/users/versioning) and
[releases](https://typescript-eslint.io/users/releases) on our website.
</details>
---
### Configuration
📅 **Schedule**: (in timezone Asia/Shanghai)
- Branch creation
- "before 10am on monday"
- Automerge
- At any time (no schedule defined)
🚦 **Automerge**: Enabled.
♻ **Rebasing**: Whenever PR is behind base branch, or you tick the
rebase/retry checkbox.
👻 **Immortal**: This PR will be recreated if closed unmerged. Get
[config
help](https://redirect.github.com/renovatebot/renovate/discussions) if
that's undesired.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/oxc-project/eslint-plugin-oxlint).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0My4xNzkuMyIsInVwZGF0ZWRJblZlciI6IjQzLjE3OS4zIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6W119-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>1 parent 1773dc2 commit a4cd2d5
2 files changed
Lines changed: 93 additions & 93 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
72 | 72 | | |
73 | 73 | | |
74 | 74 | | |
75 | | - | |
| 75 | + | |
76 | 76 | | |
0 commit comments