Skip to content

chore: update lockfile, Node.js, pnpm, and pacquet versions#12441

Merged
zkochan merged 2 commits into
mainfrom
chore/update-lockfile
Jun 18, 2026
Merged

chore: update lockfile, Node.js, pnpm, and pacquet versions#12441
zkochan merged 2 commits into
mainfrom
chore/update-lockfile

Conversation

@zkochan

@zkochan zkochan commented Jun 16, 2026

Copy link
Copy Markdown
Member

This automated PR refreshes the project's pinned versions:

  • Updates the lockfile to the latest compatible versions of dependencies.
  • Bumps Node.js to the latest 26.x release, propagated into the CI, release, and benchmark workflows via the meta-updater.
  • Bumps pnpm to the latest release (packageManager and devEngines.packageManager).
  • Bumps the @pnpm/pacquet config dependency to its latest release.

Created by the update-lockfile workflow.

Summary by CodeRabbit

  • Chores
    • Updated the Node runtime version used by CI, benchmarks, and releases to the latest compatible patch.
    • Adjusted runtime version configuration to use a compatible semver range rather than a fixed value.
    • Bumped the package manager metadata to the latest patch release.
    • Pinned a workspace dependency to a newer patch version.

@qodo-free-for-open-source-projects

qodo-free-for-open-source-projects Bot commented Jun 16, 2026

Copy link
Copy Markdown

Code Review by Qodo

🐞 Bugs (3) 📘 Rule violations (0) 📜 Skill insights (0)

Grey Divider


Action required

1. Node pin sync broken 🐞 Bug ≡ Correctness
Description
Changing devEngines.runtime.version to a caret range ("^26.3.0") causes .meta-updater to stop
syncing Node versions into scripts/workflows because it assumes a concrete numeric version string.
Future Node bumps will silently stop propagating, leaving scripts/CI pinned to stale Node versions.
Code

package.json[R74-75]

+      "version": "^26.3.0",
  "onFail": "download"
Evidence
The meta-updater explicitly expects a concrete Node version and only rewrites node@runtime: in
scripts; with a caret range it won’t match and will stop syncing. It also interpolates the runtime
major into a regex without escaping/normalizing, so a leading ^ breaks the workflow rewrite logic.

package.json[21-21]
package.json[72-76]
.meta-updater/src/index.ts[298-325]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`devEngines.runtime.version` was changed from an exact version (`26.3.0`) to a caret range (`^26.3.0`). The repo’s `.meta-updater` logic that keeps scripts and workflow Node versions in sync assumes a concrete numeric version and only rewrites `node@runtime:<digits>` patterns. With a caret-prefixed version, script rewriting and workflow version rewriting can silently stop working.
## Issue Context
`.meta-updater/src/index.ts` is explicitly documented as keeping Node pinned in scripts and workflows based on `devEngines.runtime`.
## Fix Focus Areas
- package.json[21-21]
- package.json[72-76]
- .meta-updater/src/index.ts[298-325]
## Suggested fix
- Prefer restoring an **exact** Node pin:
- `devEngines.runtime.version: "26.3.0"`
- `compile-only`: `pnx node@runtime:26.3.0 ...`
- If ranges are intentionally desired, update `.meta-updater` to:
- accept `node@runtime:` with optional range operators (e.g. `^`, `~`, `>=`)
- escape/normalize the major when building regexes for workflow rewriting (e.g. strip leading range operators before `version.split('.')`).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Remediation recommended

2. Dlx Node version drift 🐞 Bug ☼ Reliability
Description
compile-only now runs pnx node@runtime:^26.3.0, which resolves via pnpm dlx; this selects the
max-satisfying Node release at invocation time, so the Node binary used for typechecking can change
over time. This reduces CI/build reproducibility compared to the prior exact pin.
Code

package.json[21]

+    "compile-only": "tsgo --build workspace/workspace-manifest-reader workspace/projects-reader && pnx node@runtime:^26.3.0 __utils__/scripts/src/typecheck-only.ts && pn -F=pnpm compile",
Evidence
pnx is implemented as pnpm dlx, and the Node runtime resolver chooses
semver.maxSatisfying(...) for a given range. Therefore node@runtime:^26.3.0 can resolve to a
different 26.x version as new releases appear.

package.json[21-21]
pnpm/bin/pnpx.mjs[1-5]
engine/runtime/node-resolver/src/index.ts[58-71]
engine/runtime/node-resolver/src/index.ts[195-206]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`compile-only` uses `pnx node@runtime:^26.3.0 ...`. Since `pnx` is a thin wrapper over `pnpm dlx`, the caret range can resolve to a newer Node patch release later, changing the Node binary used to run the typecheck step.
## Issue Context
`pnx` rewrites argv to `pnpm dlx`, and the runtime resolver picks the latest version satisfying a range (`semver.maxSatisfying`).
## Fix Focus Areas
- package.json[21-21]
- pnpm/bin/pnpx.mjs[1-5]
- engine/runtime/node-resolver/src/index.ts[58-71]
- engine/runtime/node-resolver/src/index.ts[195-206]
## Suggested fix
- Prefer pinning `compile-only` to an exact runtime version (e.g. `pnx node@runtime:26.3.0 ...`) to keep CI/typecheck deterministic.
- Keep the exact version aligned with `devEngines.runtime.version` (and with `.meta-updater`’s expectations).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Informational

3. Yarn core duplication 🐞 Bug ➹ Performance
Description
The lockfile now includes both @yarnpkg/core@4.8.0 and @yarnpkg/core@4.9.0 because
@yarnpkg/extensions resolves against 4.8.0 while @yarnpkg/nm resolves against 4.9.0. This adds
avoidable duplication in the dependency tree (modest extra install/download footprint for
contributors/CI).
Code

pnpm-lock.yaml[R12511-12514]

+  '@yarnpkg/core@4.9.0':
+    resolution: {integrity: sha512-vhJEVo423jAZBtU5CDe2HEkyNkEYfgMfukNQk1uyYFkP3OmCsuLzpyqbJCEXIg6Fy3YTrQg7kSCnjHbLed3toA==}
+    engines: {node: '>=18.12.0'}
+
Evidence
The PR adds @yarnpkg/core@4.9.0 while @yarnpkg/core@4.8.0 remains; snapshots show
@yarnpkg/extensions using 4.8.0 and @yarnpkg/nm using 4.9.0, forcing both versions to be
installed.

pnpm-lock.yaml[12507-12520]
pnpm-lock.yaml[20347-20366]
installing/commands/src/import/index.ts[19-22]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The lockfile currently pulls two versions of `@yarnpkg/core` (`4.8.0` and `4.9.0`) because different Yarn packages resolve against different core versions. This creates unnecessary duplication in the dependency graph.
## Issue Context
`@yarnpkg/extensions@2.0.6` has a peer range that should allow using the newer core, but the snapshot is currently pinned to `@yarnpkg/core@4.8.0` while `@yarnpkg/nm@4.0.7` uses `@yarnpkg/core@4.9.0`.
## Fix Focus Areas
- pnpm-lock.yaml[12507-12520]
- pnpm-lock.yaml[20347-20366]
## Suggested fix
- Prefer a single `@yarnpkg/core` version (likely `4.9.0`) by either:
- Updating Yarn-related deps so they can all resolve against the same `@yarnpkg/core` (e.g., bump `@yarnpkg/extensions` if needed), or
- Adding a `pnpm.overrides`/workspace override to force `@yarnpkg/core@4.9.0`.
- Re-run `pnpm install` to regenerate `pnpm-lock.yaml` and confirm only one `@yarnpkg/core` version is present.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Grey Divider

Previous review results

Review updated until commit 80c9921

Results up to commit 4da6349


🐞 Bugs (3) 📘 Rule violations (0) 📜 Skill insights (0)


Action required
1. Node pin sync broken 🐞 Bug ≡ Correctness
Description
Changing devEngines.runtime.version to a caret range ("^26.3.0") causes .meta-updater to stop
syncing Node versions into scripts/workflows because it assumes a concrete numeric version string.
Future Node bumps will silently stop propagating, leaving scripts/CI pinned to stale Node versions.
Code

package.json[R74-75]

+      "version": "^26.3.0",
   "onFail": "download"
Evidence
The meta-updater explicitly expects a concrete Node version and only rewrites node@runtime: in
scripts; with a caret range it won’t match and will stop syncing. It also interpolates the runtime
major into a regex without escaping/normalizing, so a leading ^ breaks the workflow rewrite logic.

package.json[21-21]
package.json[72-76]
.meta-updater/src/index.ts[298-325]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`devEngines.runtime.version` was changed from an exact version (`26.3.0`) to a caret range (`^26.3.0`). The repo’s `.meta-updater` logic that keeps scripts and workflow Node versions in sync assumes a concrete numeric version and only rewrites `node@runtime:<digits>` patterns. With a caret-prefixed version, script rewriting and workflow version rewriting can silently stop working.
## Issue Context
`.meta-updater/src/index.ts` is explicitly documented as keeping Node pinned in scripts and workflows based on `devEngines.runtime`.
## Fix Focus Areas
- package.json[21-21]
- package.json[72-76]
- .meta-updater/src/index.ts[298-325]
## Suggested fix
- Prefer restoring an **exact** Node pin:
- `devEngines.runtime.version: "26.3.0"`
- `compile-only`: `pnx node@runtime:26.3.0 ...`
- If ranges are intentionally desired, update `.meta-updater` to:
- accept `node@runtime:` with optional range operators (e.g. `^`, `~`, `>=`)
- escape/normalize the major when building regexes for workflow rewriting (e.g. strip leading range operators before `version.split('.')`).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Remediation recommended
2. Dlx Node version drift 🐞 Bug ☼ Reliability
Description
compile-only now runs pnx node@runtime:^26.3.0, which resolves via pnpm dlx; this selects the
max-satisfying Node release at invocation time, so the Node binary used for typechecking can change
over time. This reduces CI/build reproducibility compared to the prior exact pin.
Code

package.json[21]

+    "compile-only": "tsgo --build workspace/workspace-manifest-reader workspace/projects-reader && pnx node@runtime:^26.3.0 __utils__/scripts/src/typecheck-only.ts && pn -F=pnpm compile",
Evidence
pnx is implemented as pnpm dlx, and the Node runtime resolver chooses
semver.maxSatisfying(...) for a given range. Therefore node@runtime:^26.3.0 can resolve to a
different 26.x version as new releases appear.

package.json[21-21]
pnpm/bin/pnpx.mjs[1-5]
engine/runtime/node-resolver/src/index.ts[58-71]
engine/runtime/node-resolver/src/index.ts[195-206]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`compile-only` uses `pnx node@runtime:^26.3.0 ...`. Since `pnx` is a thin wrapper over `pnpm dlx`, the caret range can resolve to a newer Node patch release later, changing the Node binary used to run the typecheck step.
## Issue Context
`pnx` rewrites argv to `pnpm dlx`, and the runtime resolver picks the latest version satisfying a range (`semver.maxSatisfying`).
## Fix Focus Areas
- package.json[21-21]
- pnpm/bin/pnpx.mjs[1-5]
- engine/runtime/node-resolver/src/index.ts[58-71]
- engine/runtime/node-resolver/src/index.ts[195-206]
## Suggested fix
- Prefer pinning `compile-only` to an exact runtime version (e.g. `pnx node@runtime:26.3.0 ...`) to keep CI/typecheck deterministic.
- Keep the exact version aligned with `devEngines.runtime.version` (and with `.meta-updater`’s expectations).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Informational
3. Yarn core duplication 🐞 Bug ➹ Performance
Description
The lockfile now includes both @yarnpkg/core@4.8.0 and @yarnpkg/core@4.9.0 because
@yarnpkg/extensions resolves against 4.8.0 while @yarnpkg/nm resolves against 4.9.0. This adds
avoidable duplication in the dependency tree (modest extra install/download footprint for
contributors/CI).
Code

pnpm-lock.yaml[R12511-12514]

+  '@yarnpkg/core@4.9.0':
+    resolution: {integrity: sha512-vhJEVo423jAZBtU5CDe2HEkyNkEYfgMfukNQk1uyYFkP3OmCsuLzpyqbJCEXIg6Fy3YTrQg7kSCnjHbLed3toA==}
+    engines: {node: '>=18.12.0'}
+
Evidence
The PR adds @yarnpkg/core@4.9.0 while @yarnpkg/core@4.8.0 remains; snapshots show
@yarnpkg/extensions using 4.8.0 and @yarnpkg/nm using 4.9.0, forcing both versions to be
installed.

pnpm-lock.yaml[12507-12520]
pnpm-lock.yaml[20347-20366]
installing/commands/src/import/index.ts[19-22]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The lockfile currently pulls two versions of `@yarnpkg/core` (`4.8.0` and `4.9.0`) because different Yarn packages resolve against different core versions. This creates unnecessary duplication in the dependency graph.
## Issue Context
`@yarnpkg/extensions@2.0.6` has a peer range that should allow using the newer core, but the snapshot is currently pinned to `@yarnpkg/core@4.8.0` while `@yarnpkg/nm@4.0.7` uses `@yarnpkg/core@4.9.0`.
## Fix Focus Areas
- pnpm-lock.yaml[12507-12520]
- pnpm-lock.yaml[20347-20366]
## Suggested fix
- Prefer a single `@yarnpkg/core` version (likely `4.9.0`) by either:
- Updating Yarn-related deps so they can all resolve against the same `@yarnpkg/core` (e.g., bump `@yarnpkg/extensions` if needed), or
- Adding a `pnpm.overrides`/workspace override to force `@yarnpkg/core@4.9.0`.
- Re-run `pnpm install` to regenerate `pnpm-lock.yaml` and confirm only one `@yarnpkg/core` version is present.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Results up to commit 5ae0fd9


🐞 Bugs (3) 📘 Rule violations (0) 📜 Skill insights (0)


Action required
1. Node pin sync broken 🐞 Bug ≡ Correctness
Description
Changing devEngines.runtime.version to a caret range ("^26.3.0") causes .meta-updater to stop
syncing Node versions into scripts/workflows because it assumes a concrete numeric version string.
Future Node bumps will silently stop propagating, leaving scripts/CI pinned to stale Node versions.
Code

package.json[R74-75]

+      "version": "^26.3.0",
    "onFail": "download"
Evidence
The meta-updater explicitly expects a concrete Node version and only rewrites node@runtime: in
scripts; with a caret range it won’t match and will stop syncing. It also interpolates the runtime
major into a regex without escaping/normalizing, so a leading ^ breaks the workflow rewrite logic.

package.json[21-21]
package.json[72-76]
.meta-updater/src/index.ts[298-325]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`devEngines.runtime.version` was changed from an exact version (`26.3.0`) to a caret range (`^26.3.0`). The repo’s `.meta-updater` logic that keeps scripts and workflow Node versions in sync assumes a concrete numeric version and only rewrites `node@runtime:<digits>` patterns. With a caret-prefixed version, script rewriting and workflow version rewriting can silently stop working.
## Issue Context
`.meta-updater/src/index.ts` is explicitly documented as keeping Node pinned in scripts and workflows based on `devEngines.runtime`.
## Fix Focus Areas
- package.json[21-21]
- package.json[72-76]
- .meta-updater/src/index.ts[298-325]
## Suggested fix
- Prefer restoring an **exact** Node pin:
- `devEngines.runtime.version: "26.3.0"`
- `compile-only`: `pnx node@runtime:26.3.0 ...`
- If ranges are intentionally desired, update `.meta-updater` to:
- accept `node@runtime:` with optional range operators (e.g. `^`, `~`, `>=`)
- escape/normalize the major when building regexes for workflow rewriting (e.g. strip leading range operators before `version.split('.')`).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Remediation recommended
2. Dlx Node version drift 🐞 Bug ☼ Reliability
Description
compile-only now runs pnx node@runtime:^26.3.0, which resolves via pnpm dlx; this selects the
max-satisfying Node release at invocation time, so the Node binary used for typechecking can change
over time. This reduces CI/build reproducibility compared to the prior exact pin.
Code

package.json[21]

+    "compile-only": "tsgo --build workspace/workspace-manifest-reader workspace/projects-reader && pnx node@runtime:^26.3.0 __utils__/scripts/src/typecheck-only.ts && pn -F=pnpm compile",
Evidence
pnx is implemented as pnpm dlx, and the Node runtime resolver chooses
semver.maxSatisfying(...) for a given range. Therefore node@runtime:^26.3.0 can resolve to a
different 26.x version as new releases appear.

package.json[21-21]
pnpm/bin/pnpx.mjs[1-5]
engine/runtime/node-resolver/src/index.ts[58-71]
engine/runtime/node-resolver/src/index.ts[195-206]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`compile-only` uses `pnx node@runtime:^26.3.0 ...`. Since `pnx` is a thin wrapper over `pnpm dlx`, the caret range can resolve to a newer Node patch release later, changing the Node binary used to run the typecheck step.
## Issue Context
`pnx` rewrites argv to `pnpm dlx`, and the runtime resolver picks the latest version satisfying a range (`semver.maxSatisfying`).
## Fix Focus Areas
- package.json[21-21]
- pnpm/bin/pnpx.mjs[1-5]
- engine/runtime/node-resolver/src/index.ts[58-71]
- engine/runtime/node-resolver/src/index.ts[195-206]
## Suggested fix
- Prefer pinning `compile-only` to an exact runtime version (e.g. `pnx node@runtime:26.3.0 ...`) to keep CI/typecheck deterministic.
- Keep the exact version aligned with `devEngines.runtime.version` (and with `.meta-updater`’s expectations).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Informational
3. Yarn core duplication 🐞 Bug ➹ Performance ⭐ New
Description
The lockfile now includes both @yarnpkg/core@4.8.0 and @yarnpkg/core@4.9.0 because
@yarnpkg/extensions resolves against 4.8.0 while @yarnpkg/nm resolves against 4.9.0. This adds
avoidable duplication in the dependency tree (modest extra install/download footprint for
contributors/CI).
Code

pnpm-lock.yaml[R12511-12514]

+  '@yarnpkg/core@4.9.0':
+    resolution: {integrity: sha512-vhJEVo423jAZBtU5CDe2HEkyNkEYfgMfukNQk1uyYFkP3OmCsuLzpyqbJCEXIg6Fy3YTrQg7kSCnjHbLed3toA==}
+    engines: {node: '>=18.12.0'}
+
Evidence
The PR adds @yarnpkg/core@4.9.0 while @yarnpkg/core@4.8.0 remains; snapshots show
@yarnpkg/extensions using 4.8.0 and @yarnpkg/nm using 4.9.0, forcing both versions to be
installed.

pnpm-lock.yaml[12507-12520]
pnpm-lock.yaml[20347-20366]
installing/commands/src/import/index.ts[19-22]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The lockfile currently pulls two versions of `@yarnpkg/core` (`4.8.0` and `4.9.0`) because different Yarn packages resolve against different core versions. This creates unnecessary duplication in the dependency graph.

## Issue Context
`@yarnpkg/extensions@2.0.6` has a peer range that should allow using the newer core, but the snapshot is currently pinned to `@yarnpkg/core@4.8.0` while `@yarnpkg/nm@4.0.7` uses `@yarnpkg/core@4.9.0`.

## Fix Focus Areas
- pnpm-lock.yaml[12507-12520]
- pnpm-lock.yaml[20347-20366]

## Suggested fix
- Prefer a single `@yarnpkg/core` version (likely `4.9.0`) by either:
 - Updating Yarn-related deps so they can all resolve against the same `@yarnpkg/core` (e.g., bump `@yarnpkg/extensions` if needed), or
 - Adding a `pnpm.overrides`/workspace override to force `@yarnpkg/core@4.9.0`.
- Re-run `pnpm install` to regenerate `pnpm-lock.yaml` and confirm only one `@yarnpkg/core` version is present.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Results up to commit 25d8a4d


🐞 Bugs (2) 📘 Rule violations (0) 📜 Skill insights (0)


Action required
1. Node pin sync broken 🐞 Bug ≡ Correctness
Description
Changing devEngines.runtime.version to a caret range ("^26.3.0") causes .meta-updater to stop
syncing Node versions into scripts/workflows because it assumes a concrete numeric version string.
Future Node bumps will silently stop propagating, leaving scripts/CI pinned to stale Node versions.
Code

package.json[R74-75]

+      "version": "^26.3.0",
     "onFail": "download"
Evidence
The meta-updater explicitly expects a concrete Node version and only rewrites node@runtime: in
scripts; with a caret range it won’t match and will stop syncing. It also interpolates the runtime
major into a regex without escaping/normalizing, so a leading ^ breaks the workflow rewrite logic.

package.json[21-21]
package.json[72-76]
.meta-updater/src/index.ts[298-325]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`devEngines.runtime.version` was changed from an exact version (`26.3.0`) to a caret range (`^26.3.0`). The repo’s `.meta-updater` logic that keeps scripts and workflow Node versions in sync assumes a concrete numeric version and only rewrites `node@runtime:<digits>` patterns. With a caret-prefixed version, script rewriting and workflow version rewriting can silently stop working.
## Issue Context
`.meta-updater/src/index.ts` is explicitly documented as keeping Node pinned in scripts and workflows based on `devEngines.runtime`.
## Fix Focus Areas
- package.json[21-21]
- package.json[72-76]
- .meta-updater/src/index.ts[298-325]
## Suggested fix
- Prefer restoring an **exact** Node pin:
- `devEngines.runtime.version: "26.3.0"`
- `compile-only`: `pnx node@runtime:26.3.0 ...`
- If ranges are intentionally desired, update `.meta-updater` to:
- accept `node@runtime:` with optional range operators (e.g. `^`, `~`, `>=`)
- escape/normalize the major when building regexes for workflow rewriting (e.g. strip leading range operators before `version.split('.')`).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Remediation recommended
2. Dlx Node version drift 🐞 Bug ☼ Reliability
Description
compile-only now runs pnx node@runtime:^26.3.0, which resolves via pnpm dlx; this selects the
max-satisfying Node release at invocation time, so the Node binary used for typechecking can change
over time. This reduces CI/build reproducibility compared to the prior exact pin.
Code

package.json[21]

+    "compile-only": "tsgo --build workspace/workspace-manifest-reader workspace/projects-reader && pnx node@runtime:^26.3.0 __utils__/scripts/src/typecheck-only.ts && pn -F=pnpm compile",
Evidence
pnx is implemented as pnpm dlx, and the Node runtime resolver chooses
semver.maxSatisfying(...) for a given range. Therefore node@runtime:^26.3.0 can resolve to a
different 26.x version as new releases appear.

package.json[21-21]
pnpm/bin/pnpx.mjs[1-5]
engine/runtime/node-resolver/src/index.ts[58-71]
engine/runtime/node-resolver/src/index.ts[195-206]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`compile-only` uses `pnx node@runtime:^26.3.0 ...`. Since `pnx` is a thin wrapper over `pnpm dlx`, the caret range can resolve to a newer Node patch release later, changing the Node binary used to run the typecheck step.
## Issue Context
`pnx` rewrites argv to `pnpm dlx`, and the runtime resolver picks the latest version satisfying a range (`semver.maxSatisfying`).
## Fix Focus Areas
- package.json[21-21]
- pnpm/bin/pnpx.mjs[1-5]
- engine/runtime/node-resolver/src/index.ts[58-71]
- engine/runtime/node-resolver/src/index.ts[195-206]
## Suggested fix
- Prefer pinning `compile-only` to an exact runtime version (e.g. `pnx node@runtime:26.3.0 ...`) to keep CI/typecheck deterministic.
- Keep the exact version aligned with `devEngines.runtime.version` (and with `.meta-updater`’s expectations).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Results up to commit 1b0dcfb


🐞 Bugs (2) 📘 Rule violations (0)


Action required
1. Node pin sync broken 🐞 Bug ≡ Correctness
Description
Changing devEngines.runtime.version to a caret range ("^26.3.0") causes .meta-updater to stop
syncing Node versions into scripts/workflows because it assumes a concrete numeric version string.
Future Node bumps will silently stop propagating, leaving scripts/CI pinned to stale Node versions.
Code

package.json[R74-75]

+      "version": "^26.3.0",
      "onFail": "download"
Evidence
The meta-updater explicitly expects a concrete Node version and only rewrites
node@runtime:<digits> in scripts; with a caret range it won’t match and will stop syncing. It also
interpolates the runtime major into a regex without escaping/normalizing, so a leading ^ breaks
the workflow rewrite logic.

package.json[21-21]
package.json[72-76]
.meta-updater/src/index.ts[298-325]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`devEngines.runtime.version` was changed from an exact version (`26.3.0`) to a caret range (`^26.3.0`). The repo’s `.meta-updater` logic that keeps scripts and workflow Node versions in sync assumes a concrete numeric version and only rewrites `node@runtime:<digits>` patterns. With a caret-prefixed version, script rewriting and workflow version rewriting can silently stop working.

## Issue Context
`.meta-updater/src/index.ts` is explicitly documented as keeping Node pinned in scripts and workflows based on `devEngines.runtime`.

## Fix Focus Areas
- package.json[21-21]
- package.json[72-76]
- .meta-updater/src/index.ts[298-325]

## Suggested fix
- Prefer restoring an **exact** Node pin:
 - `devEngines.runtime.version: "26.3.0"`
 - `compile-only`: `pnx node@runtime:26.3.0 ...`
- If ranges are intentionally desired, update `.meta-updater` to:
 - accept `node@runtime:` with optional range operators (e.g. `^`, `~`, `>=`)
 - escape/normalize the major when building regexes for workflow rewriting (e.g. strip leading range operators before `version.split('.')`).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Remediation recommended
2. Dlx Node version drift 🐞 Bug ☼ Reliability
Description
compile-only now runs pnx node@runtime:^26.3.0, which resolves via pnpm dlx; this selects the
max-satisfying Node release at invocation time, so the Node binary used for typechecking can change
over time. This reduces CI/build reproducibility compared to the prior exact pin.
Code

package.json[21]

+    "compile-only": "tsgo --build workspace/workspace-manifest-reader workspace/projects-reader && pnx node@runtime:^26.3.0 __utils__/scripts/src/typecheck-only.ts && pn -F=pnpm compile",
Evidence
pnx is implemented as pnpm dlx, and the Node runtime resolver chooses
semver.maxSatisfying(...) for a given range. Therefore node@runtime:^26.3.0 can resolve to a
different 26.x version as new releases appear.

package.json[21-21]
pnpm/bin/pnpx.mjs[1-5]
engine/runtime/node-resolver/src/index.ts[58-71]
engine/runtime/node-resolver/src/index.ts[195-206]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`compile-only` uses `pnx node@runtime:^26.3.0 ...`. Since `pnx` is a thin wrapper over `pnpm dlx`, the caret range can resolve to a newer Node patch release later, changing the Node binary used to run the typecheck step.

## Issue Context
`pnx` rewrites argv to `pnpm dlx`, and the runtime resolver picks the latest version satisfying a range (`semver.maxSatisfying`).

## Fix Focus Areas
- package.json[21-21]
- pnpm/bin/pnpx.mjs[1-5]
- engine/runtime/node-resolver/src/index.ts[58-71]
- engine/runtime/node-resolver/src/index.ts[195-206]

## Suggested fix
- Prefer pinning `compile-only` to an exact runtime version (e.g. `pnx node@runtime:26.3.0 ...`) to keep CI/typecheck deterministic.
- Keep the exact version aligned with `devEngines.runtime.version` (and with `.meta-updater`’s expectations).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Qodo Logo

@coderabbitai

coderabbitai Bot commented Jun 16, 2026

Copy link
Copy Markdown

Review Change Stack

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

  • @coderabbitai resume to resume automatic reviews.
  • @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

  • ▶️ Resume reviews
  • 🔍 Trigger review

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 218c8ff8-13c9-4a7d-9827-9a2c272940c6

📥 Commits

Reviewing files that changed from the base of the PR and between 4da6349 and 80c9921.

⛔ Files ignored due to path filters (1)
  • pnpm-lock.yaml is excluded by !**/pnpm-lock.yaml, !pnpm-lock.yaml
📒 Files selected for processing (4)
  • .github/workflows/benchmark.yml
  • .github/workflows/ci.yml
  • .github/workflows/release.yml
  • package.json
✅ Files skipped from review due to trivial changes (2)
  • .github/workflows/benchmark.yml
  • .github/workflows/ci.yml
🚧 Files skipped from review as they are similar to previous changes (1)
  • package.json

📝 Walkthrough

Walkthrough

Three configuration-only updates: package.json switches the Node runtime version specifier from exact 26.3.0 to caret range ^26.3.1 in both the compile-only script and the devEngines.runtime.version field, and bumps pnpm from 11.7.0 to 11.8.0 in packageManager and devEngines.packageManager.version; pnpm-workspace.yaml bumps @pnpm/pacquet in configDependencies from 0.11.7 to 0.11.10; GitHub Actions workflows updated to Node 26.3.1.

Changes

Config Version Updates

Layer / File(s) Summary
Node runtime loosened to caret range and pnpm toolchain bumped
package.json
The compile-only script's node@runtime selector and devEngines.runtime.version both changed from exact 26.3.0 to ^26.3.1; the packageManager and devEngines.packageManager.version both bumped from pnpm@11.7.0 to pnpm@11.8.0.
@pnpm/pacquet pinned to 0.11.10
pnpm-workspace.yaml
configDependencies entry for @pnpm/pacquet updated from 0.11.7 to 0.11.10.
Workflow Node runtime version consistency
.github/workflows/benchmark.yml, .github/workflows/ci.yml, .github/workflows/release.yml
CI, benchmark, and release GitHub Actions workflows all updated from Node 26.3.0 to 26.3.1, ensuring consistent runtime versions across the build and deployment pipeline.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Possibly related PRs

  • pnpm/pnpm#12421: Updates the same pnpm-workspace.yaml configDependencies['@pnpm/pacquet'] field, the immediate predecessor version progression in that dependency.
  • pnpm/pnpm#12014: Modifies the same package.json devEngines.runtime.version and compile-only script pnx node@runtime target, establishing the 26.3.0 baseline that this PR now relaxes to ^26.3.1.
  • pnpm/pnpm#12211: Updates the same package.json packageManager and devEngines.packageManager.version fields to bump the pnpm toolchain version, the same two fields modified here.
🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title 'chore: update lockfile, Node.js, pnpm, and pacquet versions' follows the Conventional Commits specification with the 'chore:' prefix and accurately describes all main changes in the PR.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch chore/update-lockfile

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@qodo-free-for-open-source-projects

Copy link
Copy Markdown

PR Summary by Qodo

Refresh lockfile; bump Node runtime range and @pnpm/pacquet to 0.11.8
⚙️ Configuration changes 🕐 10-20 Minutes

Grey Divider

Walkthroughs

Description
• Update pnpm lockfile to latest compatible dependency resolutions.
• Relax Node runtime pin to ^26.3.0 for build/typecheck tooling.
• Bump @pnpm/pacquet config dependency from 0.11.7 to 0.11.8.
Diagram
graph TD
  DEV(["Dev/CI"]) --> PJ["package.json"] --> NR(["Node runtime ^26.3.0"])
  PJ --> PN(["pnpm"]) --> LOCK["pnpm-lock.yaml"] --> PQ(["@pnpm/pacquet 0.11.8"])
  WS["pnpm-workspace.yaml"] --> PQ

  subgraph Legend
    direction LR
    _cfg["Config file"] ~~~ _tool(["Tool/runtime"]) 
  end
Loading
High-Level Assessment

The following are alternative approaches to this PR:

1. Keep an exact Node patch pin (e.g., 26.3.0)
  • ➕ Maximizes build reproducibility across CI/dev machines
  • ➕ Reduces risk of unexpected behavior changes from patch releases
  • ➖ Requires more frequent maintenance PRs for patch/security updates
  • ➖ Can cause unnecessary CI friction when older patches fall out of cache/support
2. Move Node version management to a dedicated toolchain file (.nvmrc/.tool-versions)
  • ➕ Single canonical source of truth for Node across local dev and CI
  • ➕ Many tools integrate directly with these formats
  • ➖ May duplicate or conflict with existing runtime management (pnx/runtime) conventions
  • ➖ Requires updating CI/workflows to respect the chosen file

Recommendation: The current approach (switching to a caret range ^26.3.0 while updating the lockfile) is reasonable if the project intends to automatically float to newer 26.x patch releases for security and reduced maintenance. If strict reproducibility is a priority, consider reverting to an exact Node patch pin; otherwise, keep the range and rely on CI to catch any patch-level regressions.

Grey Divider

File Changes

Other (3)
package.json Relax Node runtime pin to ^26.3.0 for compile/typecheck +2/-2

Relax Node runtime pin to ^26.3.0 for compile/typecheck

• Updates the runtime node version from a fixed 26.3.0 to ^26.3.0 in both the runtime config and the compile-only script invocation. This allows patch-level Node updates without changing the manifest each time.

package.json


pnpm-lock.yaml Refresh lockfile; bump pacquet to 0.11.8 and update resolutions +57/-89

Refresh lockfile; bump pacquet to 0.11.8 and update resolutions

• Bumps @pnpm/pacquet from 0.11.7 to 0.11.8 and updates all platform-specific @pacquet/* packages accordingly. Also refreshes lockfile resolutions, including a change in @types/node resolution used in Jest-related snapshots, and updates the node runtime specifier to runtime:^26.3.0.

pnpm-lock.yaml


pnpm-workspace.yaml Bump workspace configDependency @pnpm/pacquet to 0.11.8 +1/-1

Bump workspace configDependency @pnpm/pacquet to 0.11.8

• Updates the workspace-level configDependencies entry for @pnpm/pacquet from 0.11.7 to 0.11.8 to match the refreshed lockfile.

pnpm-workspace.yaml


Grey Divider

Qodo Logo

Comment thread package.json Outdated
Comment on lines 74 to 75
"version": "^26.3.0",
"onFail": "download"

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Action required

1. Node pin sync broken 🐞 Bug ≡ Correctness

Changing devEngines.runtime.version to a caret range ("^26.3.0") causes .meta-updater to stop
syncing Node versions into scripts/workflows because it assumes a concrete numeric version string.
Future Node bumps will silently stop propagating, leaving scripts/CI pinned to stale Node versions.
Agent Prompt
## Issue description
`devEngines.runtime.version` was changed from an exact version (`26.3.0`) to a caret range (`^26.3.0`). The repo’s `.meta-updater` logic that keeps scripts and workflow Node versions in sync assumes a concrete numeric version and only rewrites `node@runtime:<digits>` patterns. With a caret-prefixed version, script rewriting and workflow version rewriting can silently stop working.

## Issue Context
`.meta-updater/src/index.ts` is explicitly documented as keeping Node pinned in scripts and workflows based on `devEngines.runtime`.

## Fix Focus Areas
- package.json[21-21]
- package.json[72-76]
- .meta-updater/src/index.ts[298-325]

## Suggested fix
- Prefer restoring an **exact** Node pin:
  - `devEngines.runtime.version: "26.3.0"`
  - `compile-only`: `pnx node@runtime:26.3.0 ...`
- If ranges are intentionally desired, update `.meta-updater` to:
  - accept `node@runtime:` with optional range operators (e.g. `^`, `~`, `>=`)
  - escape/normalize the major when building regexes for workflow rewriting (e.g. strip leading range operators before `version.split('.')`).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Comment thread package.json Outdated
"ci:test-branch": "pn prepare-fixtures && pn test-pkgs-branch",
"test-pkgs-branch": "pn remove-temp-dir && pn --workspace-concurrency=1 --filter=...[origin/main] --no-sort --if-present .test",
"compile-only": "tsgo --build workspace/workspace-manifest-reader workspace/projects-reader && pnx node@runtime:26.3.0 __utils__/scripts/src/typecheck-only.ts && pn -F=pnpm compile",
"compile-only": "tsgo --build workspace/workspace-manifest-reader workspace/projects-reader && pnx node@runtime:^26.3.0 __utils__/scripts/src/typecheck-only.ts && pn -F=pnpm compile",

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remediation recommended

2. Dlx node version drift 🐞 Bug ☼ Reliability

compile-only now runs pnx node@runtime:^26.3.0, which resolves via pnpm dlx; this selects the
max-satisfying Node release at invocation time, so the Node binary used for typechecking can change
over time. This reduces CI/build reproducibility compared to the prior exact pin.
Agent Prompt
## Issue description
`compile-only` uses `pnx node@runtime:^26.3.0 ...`. Since `pnx` is a thin wrapper over `pnpm dlx`, the caret range can resolve to a newer Node patch release later, changing the Node binary used to run the typecheck step.

## Issue Context
`pnx` rewrites argv to `pnpm dlx`, and the runtime resolver picks the latest version satisfying a range (`semver.maxSatisfying`).

## Fix Focus Areas
- package.json[21-21]
- pnpm/bin/pnpx.mjs[1-5]
- engine/runtime/node-resolver/src/index.ts[58-71]
- engine/runtime/node-resolver/src/index.ts[195-206]

## Suggested fix
- Prefer pinning `compile-only` to an exact runtime version (e.g. `pnx node@runtime:26.3.0 ...`) to keep CI/typecheck deterministic.
- Keep the exact version aligned with `devEngines.runtime.version` (and with `.meta-updater`’s expectations).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

@github-actions

github-actions Bot commented Jun 16, 2026

Copy link
Copy Markdown
Contributor

Integrated-Benchmark Report (Linux)

Each scenario reports direct installs and pnpr installs. Bencher consumes pacquet@HEAD and pnpr@HEAD.

Scenario: Isolated linker: fresh restore, cold cache + cold store

Command Mean [s] Min [s] Max [s] Relative
pacquet@HEAD 3.989 ± 0.131 3.837 4.236 1.92 ± 0.15
pacquet@main 4.042 ± 0.154 3.894 4.333 1.94 ± 0.16
pnpr@HEAD 2.086 ± 0.146 1.955 2.371 1.00 ± 0.10
pnpr@main 2.079 ± 0.150 1.959 2.363 1.00
BENCHMARK_REPORT.json
{
  "results": [
    {
      "command": "pacquet@HEAD",
      "mean": 3.98859801618,
      "stddev": 0.13085201755669126,
      "median": 3.95076147368,
      "user": 3.7575503999999995,
      "system": 3.47022514,
      "min": 3.83675558618,
      "max": 4.23572649418,
      "times": [
        4.02325118918,
        4.23572649418,
        3.93025820518,
        3.94191148618,
        4.16856603218,
        3.9596114611799997,
        3.8623964421799997,
        4.04374353318,
        3.8837597321799997,
        3.83675558618
      ]
    },
    {
      "command": "pacquet@main",
      "mean": 4.04235469478,
      "stddev": 0.15384508005232755,
      "median": 4.01592388818,
      "user": 3.7258389999999997,
      "system": 3.4796645400000004,
      "min": 3.89397400418,
      "max": 4.33328321318,
      "times": [
        4.33328321318,
        3.89397400418,
        4.0399954741799995,
        3.90061068318,
        4.03409870418,
        3.92484296118,
        3.9179190771799997,
        4.26468080018,
        3.99774907218,
        4.11639295818
      ]
    },
    {
      "command": "pnpr@HEAD",
      "mean": 2.08597532718,
      "stddev": 0.14599013847278974,
      "median": 2.01875596968,
      "user": 2.6305908000000002,
      "system": 2.98252614,
      "min": 1.9546679851800002,
      "max": 2.3706040651799998,
      "times": [
        2.0061507441799997,
        2.1636754041799997,
        1.98689829718,
        2.01683083018,
        1.9546679851800002,
        2.00256683318,
        2.3706040651799998,
        2.0246111021799997,
        2.02068110918,
        2.31306690118
      ]
    },
    {
      "command": "pnpr@main",
      "mean": 2.07851547308,
      "stddev": 0.14999816350584003,
      "median": 2.0134274456799996,
      "user": 2.6509813999999996,
      "system": 2.9634997399999996,
      "min": 1.9585390091800001,
      "max": 2.36283526618,
      "times": [
        2.07042177618,
        2.35004569218,
        2.00639515118,
        2.36283526618,
        1.9585390091800001,
        2.0146624691799997,
        2.0114477051799997,
        1.96225610518,
        2.01219242218,
        2.03635913418
      ]
    }
  ]
}

Scenario: Isolated linker: fresh restore, hot cache + hot store

Command Mean [ms] Min [ms] Max [ms] Relative
pacquet@HEAD 628.8 ± 13.6 609.5 646.6 1.01 ± 0.03
pacquet@main 622.5 ± 8.7 610.9 636.7 1.00
pnpr@HEAD 688.1 ± 20.8 663.6 730.6 1.11 ± 0.04
pnpr@main 698.7 ± 66.2 651.9 878.6 1.12 ± 0.11
BENCHMARK_REPORT.json
{
  "results": [
    {
      "command": "pacquet@HEAD",
      "mean": 0.6287680098600001,
      "stddev": 0.013589813178168944,
      "median": 0.6306720296600001,
      "user": 0.35775707999999995,
      "system": 1.3375898400000001,
      "min": 0.6095284656600001,
      "max": 0.64659372266,
      "times": [
        0.6240241796600001,
        0.6095284656600001,
        0.6374956846600001,
        0.6187762036600001,
        0.6413224616600001,
        0.6414355516600001,
        0.6199098166600001,
        0.6112741326600001,
        0.64659372266,
        0.63731987966
      ]
    },
    {
      "command": "pacquet@main",
      "mean": 0.6224815233600001,
      "stddev": 0.008684495295349736,
      "median": 0.6192842541600001,
      "user": 0.35949018,
      "system": 1.32075234,
      "min": 0.61092571766,
      "max": 0.6367203356600001,
      "times": [
        0.6188418986600001,
        0.6158600616600001,
        0.6290402916600001,
        0.6173899336600001,
        0.6367203356600001,
        0.6259938876600001,
        0.61092571766,
        0.61972660966,
        0.6347032836600001,
        0.6156132136600001
      ]
    },
    {
      "command": "pnpr@HEAD",
      "mean": 0.68813784296,
      "stddev": 0.02080511497172301,
      "median": 0.68475706066,
      "user": 0.38053847999999996,
      "system": 1.3514697400000002,
      "min": 0.6636051636600001,
      "max": 0.7306381476600001,
      "times": [
        0.7306381476600001,
        0.6883008726600001,
        0.67537809666,
        0.68662925866,
        0.71609861366,
        0.6908516456600001,
        0.6796965436600001,
        0.68288486266,
        0.6636051636600001,
        0.66729522466
      ]
    },
    {
      "command": "pnpr@main",
      "mean": 0.69873933356,
      "stddev": 0.06622519558620683,
      "median": 0.68141390916,
      "user": 0.38142488,
      "system": 1.3435826399999997,
      "min": 0.65185868166,
      "max": 0.8785976336600001,
      "times": [
        0.66371781766,
        0.6566762906600001,
        0.6694549636600001,
        0.65185868166,
        0.7154593946600001,
        0.70269902766,
        0.67854034066,
        0.6842874776600001,
        0.6861017076600001,
        0.8785976336600001
      ]
    }
  ]
}

Scenario: Isolated linker: fresh install, cold cache + cold store

Command Mean [s] Min [s] Max [s] Relative
pacquet@HEAD 4.183 ± 0.048 4.083 4.241 1.93 ± 0.10
pacquet@main 4.237 ± 0.109 4.086 4.375 1.95 ± 0.11
pnpr@HEAD 2.171 ± 0.105 2.052 2.354 1.00
pnpr@main 2.219 ± 0.115 2.074 2.409 1.02 ± 0.07
BENCHMARK_REPORT.json
{
  "results": [
    {
      "command": "pacquet@HEAD",
      "mean": 4.182957196359999,
      "stddev": 0.04848152399724729,
      "median": 4.189389505059999,
      "user": 3.684391099999999,
      "system": 3.36569958,
      "min": 4.08277981656,
      "max": 4.24145680756,
      "times": [
        4.16908611356,
        4.20969289656,
        4.16389078056,
        4.22685098656,
        4.22166753056,
        4.24145680756,
        4.21178103856,
        4.14250801656,
        4.08277981656,
        4.15985797656
      ]
    },
    {
      "command": "pacquet@main",
      "mean": 4.23740409906,
      "stddev": 0.10884912919221418,
      "median": 4.24809281006,
      "user": 3.7228551000000003,
      "system": 3.42499508,
      "min": 4.08642165956,
      "max": 4.37487790256,
      "times": [
        4.08642165956,
        4.09756910756,
        4.13410041556,
        4.1842910595600005,
        4.20590726156,
        4.34412835356,
        4.31788354956,
        4.33858332256,
        4.37487790256,
        4.29027835856
      ]
    },
    {
      "command": "pnpr@HEAD",
      "mean": 2.17110233086,
      "stddev": 0.10498452985456241,
      "median": 2.14688728256,
      "user": 2.4882785999999997,
      "system": 2.91641958,
      "min": 2.05179869756,
      "max": 2.3540822395600003,
      "times": [
        2.09162627256,
        2.15673018756,
        2.13764478656,
        2.06112581656,
        2.23634320556,
        2.15612977856,
        2.13363267856,
        2.33190964556,
        2.05179869756,
        2.3540822395600003
      ]
    },
    {
      "command": "pnpr@main",
      "mean": 2.21908047996,
      "stddev": 0.11471031474956225,
      "median": 2.17674604806,
      "user": 2.4634666999999997,
      "system": 2.9069058799999996,
      "min": 2.07352991556,
      "max": 2.40898279956,
      "times": [
        2.1263385655600002,
        2.20698235856,
        2.14650973756,
        2.13287738556,
        2.34728614756,
        2.3178074785600002,
        2.07352991556,
        2.13302536756,
        2.40898279956,
        2.29746504356
      ]
    }
  ]
}

Scenario: Isolated linker: fresh install, hot cache + hot store

Command Mean [s] Min [s] Max [s] Relative
pacquet@HEAD 1.335 ± 0.016 1.314 1.360 1.95 ± 0.25
pacquet@main 1.367 ± 0.089 1.307 1.613 2.00 ± 0.29
pnpr@HEAD 0.683 ± 0.087 0.646 0.929 1.00
pnpr@main 0.701 ± 0.025 0.642 0.742 1.03 ± 0.14
BENCHMARK_REPORT.json
{
  "results": [
    {
      "command": "pacquet@HEAD",
      "mean": 1.3347448928000003,
      "stddev": 0.01550626139410246,
      "median": 1.3367273186000002,
      "user": 1.3041745999999999,
      "system": 1.70794682,
      "min": 1.3138078056,
      "max": 1.3598611376,
      "times": [
        1.3598611376,
        1.3170002546000001,
        1.3302225726,
        1.3437861756000002,
        1.3432320646000002,
        1.3447409016,
        1.3230024506,
        1.3138078056,
        1.3494115906000002,
        1.3223839746000001
      ]
    },
    {
      "command": "pacquet@main",
      "mean": 1.3672929172,
      "stddev": 0.08919967771887057,
      "median": 1.3445546931,
      "user": 1.3152981000000001,
      "system": 1.7442677199999999,
      "min": 1.3067815626000001,
      "max": 1.6129354436,
      "times": [
        1.3136025246,
        1.3067815626000001,
        1.3208064066,
        1.6129354436,
        1.3654129566000002,
        1.3313690116,
        1.3339226746000001,
        1.3551867116,
        1.3684706606,
        1.3644412196
      ]
    },
    {
      "command": "pnpr@HEAD",
      "mean": 0.683455455,
      "stddev": 0.08713141263803482,
      "median": 0.6513790701,
      "user": 0.3429924999999999,
      "system": 1.27729962,
      "min": 0.6458965816,
      "max": 0.9294803036,
      "times": [
        0.6624881506,
        0.6458965816,
        0.6504818666,
        0.9294803036,
        0.6745350246,
        0.6484840826,
        0.6748987046,
        0.6479071056,
        0.6481064566,
        0.6522762736000001
      ]
    },
    {
      "command": "pnpr@main",
      "mean": 0.7006987240000001,
      "stddev": 0.025271235248903724,
      "median": 0.7029371985999999,
      "user": 0.3679018,
      "system": 1.3263591200000002,
      "min": 0.6416423546,
      "max": 0.7422232366,
      "times": [
        0.6416423546,
        0.7077141576,
        0.7032479166,
        0.6957845806,
        0.6918391066,
        0.7026264806,
        0.7422232366,
        0.7111185106,
        0.6948831906,
        0.7159077056
      ]
    }
  ]
}

Scenario: Isolated linker: fresh install, cold cache + hot store

Command Mean [s] Min [s] Max [s] Relative
pacquet@HEAD 3.315 ± 0.082 3.249 3.527 4.56 ± 0.17
pacquet@main 3.273 ± 0.032 3.217 3.312 4.50 ± 0.14
pnpr@HEAD 0.729 ± 0.014 0.710 0.756 1.00 ± 0.04
pnpr@main 0.727 ± 0.021 0.708 0.782 1.00
BENCHMARK_REPORT.json
{
  "results": [
    {
      "command": "pacquet@HEAD",
      "mean": 3.31476548038,
      "stddev": 0.08236762141336969,
      "median": 3.28985619908,
      "user": 2.03473876,
      "system": 2.1137172199999994,
      "min": 3.24854604458,
      "max": 3.52736630958,
      "times": [
        3.26878758958,
        3.35222431658,
        3.28939497058,
        3.29031742758,
        3.26228480258,
        3.26284027958,
        3.52736630958,
        3.24854604458,
        3.34674664858,
        3.29914641458
      ]
    },
    {
      "command": "pacquet@main",
      "mean": 3.27283433268,
      "stddev": 0.03209175529633655,
      "median": 3.28207956258,
      "user": 1.9927638600000002,
      "system": 2.1076006199999995,
      "min": 3.21718604258,
      "max": 3.31212905558,
      "times": [
        3.24868305758,
        3.22862840158,
        3.28950208258,
        3.31212905558,
        3.31133977458,
        3.21718604258,
        3.28536266758,
        3.28187185158,
        3.28228727358,
        3.27135311958
      ]
    },
    {
      "command": "pnpr@HEAD",
      "mean": 0.7291580633800001,
      "stddev": 0.01428315844049109,
      "median": 0.72551575008,
      "user": 0.38264376,
      "system": 1.3544000200000001,
      "min": 0.71005824058,
      "max": 0.75572382258,
      "times": [
        0.72339545358,
        0.72763604658,
        0.71965516358,
        0.74396976158,
        0.73877105358,
        0.73647187458,
        0.75572382258,
        0.72135245258,
        0.71005824058,
        0.71454676458
      ]
    },
    {
      "command": "pnpr@main",
      "mean": 0.72743983388,
      "stddev": 0.021113632685595424,
      "median": 0.7205644820799999,
      "user": 0.39229396000000005,
      "system": 1.32843172,
      "min": 0.70787424258,
      "max": 0.78214009858,
      "times": [
        0.73839167858,
        0.72691655458,
        0.73018741358,
        0.71280017358,
        0.71648280258,
        0.72080118558,
        0.78214009858,
        0.72032777858,
        0.70787424258,
        0.71847641058
      ]
    }
  ]
}

@github-actions

github-actions Bot commented Jun 16, 2026

Copy link
Copy Markdown
Contributor

🐰 Bencher Report

Branchpr/12441
Testbedpacquet
Click to view all benchmark results
BenchmarkLatencyBenchmark Result
milliseconds (ms)
(Result Δ%)
Upper Boundary
milliseconds (ms)
(Limit %)
isolated-linker.fresh-install.cold-cache.cold-store📈 view plot
🚷 view threshold
4,182.96 ms
(-0.65%)Baseline: 4,210.22 ms
5,052.26 ms
(82.79%)
isolated-linker.fresh-install.cold-cache.hot-store📈 view plot
🚷 view threshold
3,314.77 ms
(+10.61%)Baseline: 2,996.89 ms
3,596.27 ms
(92.17%)
isolated-linker.fresh-install.hot-cache.hot-store📈 view plot
🚷 view threshold
1,334.74 ms
(+0.71%)Baseline: 1,325.34 ms
1,590.41 ms
(83.92%)
isolated-linker.fresh-restore.cold-cache.cold-store📈 view plot
🚷 view threshold
3,988.60 ms
(-4.02%)Baseline: 4,155.87 ms
4,987.04 ms
(79.98%)
isolated-linker.fresh-restore.hot-cache.hot-store📈 view plot
🚷 view threshold
628.77 ms
(+1.89%)Baseline: 617.08 ms
740.50 ms
(84.91%)
🐰 View full continuous benchmarking report in Bencher

@github-actions

github-actions Bot commented Jun 16, 2026

Copy link
Copy Markdown
Contributor

🐰 Bencher Report

Branchpr/12441
Testbedpnpr

⚠️ WARNING: No Threshold found!

Without a Threshold, no Alerts will ever be generated.

Click here to create a new Threshold
For more information, see the Threshold documentation.
To only post results if a Threshold exists, set the --ci-only-thresholds flag.

Click to view all benchmark results
BenchmarkLatencymilliseconds (ms)
isolated-linker.fresh-install.cold-cache.cold-store📈 view plot
⚠️ NO THRESHOLD
2,171.10 ms
isolated-linker.fresh-install.cold-cache.hot-store📈 view plot
⚠️ NO THRESHOLD
729.16 ms
isolated-linker.fresh-install.hot-cache.hot-store📈 view plot
⚠️ NO THRESHOLD
683.46 ms
isolated-linker.fresh-restore.cold-cache.cold-store📈 view plot
⚠️ NO THRESHOLD
2,085.98 ms
isolated-linker.fresh-restore.hot-cache.hot-store📈 view plot
⚠️ NO THRESHOLD
688.14 ms
🐰 View full continuous benchmarking report in Bencher

@qodo-free-for-open-source-projects

Copy link
Copy Markdown

Code review by qodo was updated up to the latest commit 25d8a4d

@zkochan zkochan force-pushed the chore/update-lockfile branch from 25d8a4d to 5ae0fd9 Compare June 18, 2026 07:51
@github-actions github-actions Bot added the reviewed: coderabbit CodeRabbit submitted an approving review label Jun 18, 2026
@qodo-free-for-open-source-projects

Copy link
Copy Markdown

Code review by qodo was updated up to the latest commit 5ae0fd9

@zkochan zkochan force-pushed the chore/update-lockfile branch from 5ae0fd9 to 4da6349 Compare June 18, 2026 11:33
@qodo-free-for-open-source-projects

Copy link
Copy Markdown

Code review by qodo was updated up to the latest commit 4da6349

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@package.json`:
- Around line 65-71: A changeset entry is missing to document the pnpm version
bump from 11.7.0 to 11.8.0 in package.json. Create a new markdown file in the
.changeset/ directory following your project's changeset format (typically named
with a descriptor and .md extension). The changeset entry should document the
pnpm package bump as a minor version change to 11.8.0 with an appropriate
description of the update, then include this file in your commit.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 15850c3f-d633-4100-8d6d-040316a39dd9

📥 Commits

Reviewing files that changed from the base of the PR and between 5ae0fd9 and 4da6349.

⛔ Files ignored due to path filters (1)
  • pnpm-lock.yaml is excluded by !**/pnpm-lock.yaml, !pnpm-lock.yaml
📒 Files selected for processing (2)
  • package.json
  • pnpm-workspace.yaml

Comment thread package.json
@zkochan zkochan merged commit 8d17c7b into main Jun 18, 2026
22 checks passed
@zkochan zkochan deleted the chore/update-lockfile branch June 18, 2026 12:35
@qodo-free-for-open-source-projects

Copy link
Copy Markdown

Code review by qodo was updated up to the latest commit 80c9921

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

product: pacquet product: pnpm@11 reviewed: coderabbit CodeRabbit submitted an approving review

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant