Skip to content

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

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

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

Conversation

@zkochan

@zkochan zkochan commented Jun 8, 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 project package manager to pnpm 11.5.3 to align tooling across environments.
    • Bumped workspace tooling dependency @pnpm/pacquet to 0.11.2 to pick up the latest fixes and improvements.

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

Copy link
Copy Markdown

Review Summary by Qodo

Update Node.js runtime version specifier to caret range

✨ Enhancement

Grey Divider

Walkthroughs

Description
• Updates Node.js runtime version specifier to caret range
• Modifies pnpm lockfile to reflect version constraint changes
• Ensures flexible Node.js version compatibility for runtime
Diagram
flowchart LR
  A["package.json"] -- "Update node@runtime specifier" --> B["Caret range ^26.3.0"]
  C["pnpm-lock.yaml"] -- "Sync lockfile" --> B
  B -- "Allows patch updates" --> D["Flexible versioning"]

Loading

Grey Divider

File Changes

1. package.json ⚙️ Configuration changes +2/-2

Update Node.js runtime to caret version specifier

• Changes node@runtime:26.3.0 to node@runtime:^26.3.0 in compile-only script
• Updates devEngines.runtime.version from 26.3.0 to ^26.3.0
• Enables flexible patch version updates for Node.js runtime

package.json


2. pnpm-lock.yaml Dependencies +1/-2

Sync lockfile with Node.js version constraint

• Updates node specifier from runtime:26.3.0 to runtime:^26.3.0
• Removes duplicate version field in package metadata
• Synchronizes lockfile with package.json configuration changes

pnpm-lock.yaml


Grey Divider

Qodo Logo

@coderabbitai

coderabbitai Bot commented Jun 8, 2026

Copy link
Copy Markdown

Review Change Stack

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 29c7703a-e751-44ff-9476-0cb4573fb681

📥 Commits

Reviewing files that changed from the base of the PR and between 1fd4de7 and 6ef8897.

⛔ Files ignored due to path filters (1)
  • pnpm-lock.yaml is excluded by !**/pnpm-lock.yaml
📒 Files selected for processing (2)
  • package.json
  • pnpm-workspace.yaml
📜 Recent review details
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (4)
  • GitHub Check: Run benchmark on ubuntu-latest
  • GitHub Check: Compile & Lint
  • GitHub Check: Analyze (javascript)
  • GitHub Check: Compile & Lint
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2026-05-05T23:03:04.286Z
Learnt from: zkochan
Repo: pnpm/pnpm PR: 11479
File: __utils__/scripts/package.json:6-9
Timestamp: 2026-05-05T23:03:04.286Z
Learning: The pattern cross-env NODE_OPTIONS="$NODE_OPTIONS ..." in package.json scripts is an established convention in the pnpm/pnpm repository and is used across many packages (e.g., fs/hard-link-dir, worker, __utils__/scripts). Do not flag this as a cross-platform issue in individual files; if a change is needed, apply it as a repo-wide change in a separate PR. Scope this guidance to all package.json files in the repo; use the minimatch pattern '**/package.json' to identify relevant files and review changes at the repository level rather than per-file.

Applied to files:

  • package.json
🔇 Additional comments (4)
package.json (3)

20-20: LGTM!


73-73: LGTM!


64-64: pnpm@11.5.3 exists; current pnpm security advisories don’t impact this version

  • package.json (packageManager: pnpm@11.5.3, lines 64 and 68) is published on the registry (11.5.3 returned from https://registry.npmjs.org/pnpm/11.5.3).
  • The reported pnpm security advisories cover only versions < 10.28.1, < 10.28.2, < 10.27.0, < 10.26.0, or < 10.0.0—no advisory vulnerableVersionRange includes 11.5.3.
pnpm-workspace.yaml (1)

332-332: Confirm @pnpm/pacquet@0.11.2 availability + identity/security posture (pnpm-workspace.yaml: configDependencies at line 332)

  • @pnpm/pacquet@0.11.2 is present in the npm registry with dist.integrity matching pnpm-lock.yaml’s env document (sha512-MjsAWpW5K1xOaaspquMhk5j9sjpADLH3c3hxq07VVZwS9uu1W6gzMBHxlhy1NX/+ZacqMhfyScvgQqymCc1znQ==) and includes registry signatures/attestations.
  • pnpm-lock.yaml’s env document also records the platform binary identity @pacquet/linux-x64@0.11.2 with matching resolution.integrity, aligning with what verifyPacquetIdentity checks before delegating to pacquet.
  • No security advisories/vulnerabilities are reported for @pnpm/pacquet in the advisory query results.

📝 Walkthrough

Walkthrough

Bumps the pinned pnpm version in root package.json from pnpm@11.5.2pnpm@11.5.3 (and devEngines.packageManager.version 11.5.2 → 11.5.3) and updates pnpm-workspace.yaml configDependencies.@pnpm/pacquet from 0.11.10.11.2.

Changes

Tooling version updates

Layer / File(s) Summary
pnpm pin and devEngines update
package.json
packageManager changed from pnpm@11.5.2pnpm@11.5.3; devEngines.packageManager.version changed from 11.5.211.5.3.
Workspace configDependencies bump
pnpm-workspace.yaml
configDependencies.@pnpm/pacquet bumped from 0.11.10.11.2.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

  • pnpm/pnpm#12211: Updates the same package.json packageManager and devEngines.packageManager.version fields.
  • pnpm/pnpm#11893: Modifies pnpm-workspace.yaml configDependencies for @pnpm/pacquet.
  • pnpm/pnpm#12157: Also bumps @pnpm/pacquet in pnpm-workspace.yaml configDependencies.

Poem

🐰 A tiny hop, a tool that's tuned,
pnpm bumped, the locks attuned,
pacquet hopped a notch as well,
quiet changes, all is well,
carrot cheer for versions pruned.

🚥 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 accurately describes the main changes: updates to pnpm version and @pnpm/pacquet version in the changeset, matching the PR objectives.
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.

@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`:
- Line 20: The regex in .meta-updater/src/index.ts function
syncNodeRuntimeInScripts currently only matches plain numeric versions for
node@runtime and thus misses strings like node@runtime:^26.3.0 used in the
package.json compile-only script; update the regex to accept common semver range
prefixes (e.g. ^, ~, >=, <=, >, <) before the version so node@runtime:^26.3.0
will match and be replaced, and ensure you update the pattern that targets the
compile-only script's node@runtime token accordingly; also verify separately
that pnx node@runtime supports semver ranges (if it does not, revert to pinning
and adjust the meta-updater behavior).
🪄 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: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: c4cd66fc-c0c1-414f-972c-573c7d15865d

📥 Commits

Reviewing files that changed from the base of the PR and between 6f11872 and b0b1513.

⛔ Files ignored due to path filters (1)
  • pnpm-lock.yaml is excluded by !**/pnpm-lock.yaml
📒 Files selected for processing (1)
  • package.json
📜 Review details
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (4)
  • GitHub Check: Compile & Lint
  • GitHub Check: Run benchmark on ubuntu-latest
  • GitHub Check: Analyze (javascript)
  • GitHub Check: Compile & Lint
🧰 Additional context used
🧠 Learnings (14)
📓 Common learnings
Learnt from: CR
Repo: pnpm/pnpm PR: 0
File: AGENTS.md:0-0
Timestamp: 2026-06-06T22:48:27.363Z
Learning: Keep pnpm and pacquet in sync — any user-visible change (CLI flags, defaults, environment-variable handling, lockfile/manifest/state-file format, error codes and messages, log emissions, store layout, hook semantics) must land in both the TypeScript pnpm CLI and the Rust pacquet port in the same PR
Learnt from: CR
Repo: pnpm/pnpm PR: 0
File: AGENTS.md:0-0
Timestamp: 2026-06-06T22:48:27.363Z
Learning: Always explicitly include `pnpm` in changesets with the appropriate version bump; the pnpm CLI only receives automatic patch bumps from dependencies, so minor or major bumps must be specified explicitly
Learnt from: CR
Repo: pnpm/pnpm PR: 0
File: pacquet/AGENTS.md:0-0
Timestamp: 2026-05-29T18:03:15.372Z
Learning: Reference the upstream pnpm commit/PR when porting code from pnpm in commit messages
Learnt from: CR
Repo: pnpm/pnpm PR: 0
File: pacquet/AGENTS.md:0-0
Timestamp: 2026-05-29T18:03:15.372Z
Learning: Do not change lockfile format, store layout, `.npmrc` semantics, or CLI surface unless pnpm changed them first
Learnt from: CR
Repo: pnpm/pnpm PR: 0
File: AGENTS.md:0-0
Timestamp: 2026-06-06T22:48:27.363Z
Learning: After changing any package, rebuild the bundle with `pnpm --filter pnpm run compile` (which runs tsgo --build, linting, and pnpm run bundle) before running e2e tests, as pnpm CLI e2e tests use the bundled pnpm/dist/pnpm.mjs
Learnt from: zkochan
Repo: pnpm/pnpm PR: 11479
File: __utils__/scripts/package.json:6-9
Timestamp: 2026-05-05T23:03:30.044Z
Learning: In the pnpm/pnpm repository, the pattern `cross-env NODE_OPTIONS="$NODE_OPTIONS ..." jest` is an intentional, established convention used across many package.json files (e.g., `fs/hard-link-dir`, `worker`, `__utils__/scripts`). Do not flag this as a cross-platform issue in individual files; any fix should be applied repo-wide as a separate change.
Learnt from: CR
Repo: pnpm/pnpm PR: 0
File: pacquet/AGENTS.md:0-0
Timestamp: 2026-05-29T18:03:15.372Z
Learning: Match how the same feature is implemented in the TypeScript pnpm CLI — any change in pacquet must match pnpm's behavior, logic, edge cases, config resolution, error messages, file/lockfile formats, and existing tests
Learnt from: zkochan
Repo: pnpm/pnpm PR: 11734
File: installing/deps-installer/src/install/runPacquet.ts:48-51
Timestamp: 2026-05-19T07:12:00.339Z
Learning: In pnpm/pnpm, `runPacquet.ts` spawns the pacquet bin via `spawn(process.execPath, [pacquetBin, ...args], ...)` rather than `spawn(pacquetBin, args, ...)`. This is intentional: `pacquetBin` (`node_modules/.pnpm-config/pacquet/bin/pacquet`) is a Node wrapper script (starts with `#!/usr/bin/env node`) that resolves the platform-specific native binary at runtime. Spawning it directly works on Unix via shebang but silently breaks on Windows where shebangs are not honoured; using `process.execPath` ensures the launcher runs under the same Node binary on every platform. Do not flag this as a bug.
📚 Learning: 2026-06-06T22:48:27.363Z
Learnt from: CR
Repo: pnpm/pnpm PR: 0
File: AGENTS.md:0-0
Timestamp: 2026-06-06T22:48:27.363Z
Learning: Always explicitly include `pnpm` in changesets with the appropriate version bump; the pnpm CLI only receives automatic patch bumps from dependencies, so minor or major bumps must be specified explicitly

Applied to files:

  • package.json
📚 Learning: 2026-06-06T22:48:27.363Z
Learnt from: CR
Repo: pnpm/pnpm PR: 0
File: AGENTS.md:0-0
Timestamp: 2026-06-06T22:48:27.363Z
Learning: Keep pnpm and pacquet in sync — any user-visible change (CLI flags, defaults, environment-variable handling, lockfile/manifest/state-file format, error codes and messages, log emissions, store layout, hook semantics) must land in both the TypeScript pnpm CLI and the Rust pacquet port in the same PR

Applied to files:

  • package.json
📚 Learning: 2026-06-06T22:48:27.363Z
Learnt from: CR
Repo: pnpm/pnpm PR: 0
File: AGENTS.md:0-0
Timestamp: 2026-06-06T22:48:27.363Z
Learning: After changing any package, rebuild the bundle with `pnpm --filter pnpm run compile` (which runs tsgo --build, linting, and pnpm run bundle) before running e2e tests, as pnpm CLI e2e tests use the bundled pnpm/dist/pnpm.mjs

Applied to files:

  • package.json
📚 Learning: 2026-05-29T18:03:15.372Z
Learnt from: CR
Repo: pnpm/pnpm PR: 0
File: pacquet/AGENTS.md:0-0
Timestamp: 2026-05-29T18:03:15.372Z
Learning: Do not change lockfile format, store layout, `.npmrc` semantics, or CLI surface unless pnpm changed them first

Applied to files:

  • package.json
📚 Learning: 2026-05-05T23:03:04.286Z
Learnt from: zkochan
Repo: pnpm/pnpm PR: 11479
File: __utils__/scripts/package.json:6-9
Timestamp: 2026-05-05T23:03:04.286Z
Learning: The pattern cross-env NODE_OPTIONS="$NODE_OPTIONS ..." in package.json scripts is an established convention in the pnpm/pnpm repository and is used across many packages (e.g., fs/hard-link-dir, worker, __utils__/scripts). Do not flag this as a cross-platform issue in individual files; if a change is needed, apply it as a repo-wide change in a separate PR. Scope this guidance to all package.json files in the repo; use the minimatch pattern '**/package.json' to identify relevant files and review changes at the repository level rather than per-file.

Applied to files:

  • package.json
📚 Learning: 2026-05-29T18:03:15.372Z
Learnt from: CR
Repo: pnpm/pnpm PR: 0
File: pacquet/AGENTS.md:0-0
Timestamp: 2026-05-29T18:03:15.372Z
Learning: Match how the same feature is implemented in the TypeScript pnpm CLI — any change in pacquet must match pnpm's behavior, logic, edge cases, config resolution, error messages, file/lockfile formats, and existing tests

Applied to files:

  • package.json
📚 Learning: 2026-05-29T18:03:15.372Z
Learnt from: CR
Repo: pnpm/pnpm PR: 0
File: pacquet/AGENTS.md:0-0
Timestamp: 2026-05-29T18:03:15.372Z
Learning: Applies to pacquet/**/tests/**/*.rs : Port relevant pnpm tests to Rust tests whenever they translate when porting behavior from pnpm

Applied to files:

  • package.json
📚 Learning: 2026-05-29T18:03:15.372Z
Learnt from: CR
Repo: pnpm/pnpm PR: 0
File: pacquet/AGENTS.md:0-0
Timestamp: 2026-05-29T18:03:15.372Z
Learning: The `pre-push` hook runs `pacquet/scripts/pre-push-rust.sh` which checks `rustfmt`, `taplo`, `cargo doc` with `-D warnings`, and `cargo dylint`

Applied to files:

  • package.json
📚 Learning: 2026-05-29T18:03:15.372Z
Learnt from: CR
Repo: pnpm/pnpm PR: 0
File: pacquet/AGENTS.md:0-0
Timestamp: 2026-05-29T18:03:15.372Z
Learning: Applies to pacquet/**/tests/**/*.rs : Tests that need the mocked registry should start `pnpr` through `pacquet-testing-utils`; `cargo test` / `cargo nextest run` should not require a separate `just registry-mock launch` step

Applied to files:

  • package.json
📚 Learning: 2026-05-29T18:03:24.797Z
Learnt from: CR
Repo: pnpm/pnpm PR: 0
File: pnpr/AGENTS.md:0-0
Timestamp: 2026-05-29T18:03:24.797Z
Learning: Applies to pnpr/**/pnpr/**/*.rs : Follow the pacquet contributing guide (../pacquet/CONTRIBUTING.md) for test layout and Rust conventions

Applied to files:

  • package.json
📚 Learning: 2026-05-29T18:03:24.797Z
Learnt from: CR
Repo: pnpm/pnpm PR: 0
File: pnpr/AGENTS.md:0-0
Timestamp: 2026-05-29T18:03:24.797Z
Learning: Run 'just check', 'just test', 'just lint', and 'just fmt' before declaring work done

Applied to files:

  • package.json
📚 Learning: 2026-05-29T18:03:24.797Z
Learnt from: CR
Repo: pnpm/pnpm PR: 0
File: pnpr/AGENTS.md:0-0
Timestamp: 2026-05-29T18:03:24.797Z
Learning: Applies to pnpr/**/pnpr/**/*.rs : Follow the pacquet code-style guide (../pacquet/CODE_STYLE_GUIDE.md) for Rust-level conventions including imports, naming, ownership, and error handling

Applied to files:

  • package.json
📚 Learning: 2026-05-29T18:03:15.372Z
Learnt from: CR
Repo: pnpm/pnpm PR: 0
File: pacquet/AGENTS.md:0-0
Timestamp: 2026-05-29T18:03:15.372Z
Learning: Applies to pacquet/**/tests/**/*.rs : Prefer `#[cfg_attr(target_os = "windows", ignore = "...")]` (or matching `#[cfg(unix)]` gates) over runtime probe-and-skip helpers for platform-locked tools

Applied to files:

  • package.json
🔇 Additional comments (1)
package.json (1)

20-20: pnx supports semver ranges in node@runtime:<spec> selectors.
pnx node@runtime:^26.3.0 is valid: pacquet’s parse_node_specifier accepts any semver range after runtime: and forwards it to resolve_node_version, and the repo lockfile already uses specifier: runtime:^26.3.0.

Comment thread package.json Outdated
@github-actions

github-actions Bot commented Jun 8, 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 10.341 ± 0.126 10.226 10.644 1.92 ± 0.03
pacquet@main 10.351 ± 0.169 10.213 10.746 1.92 ± 0.03
pnpr@HEAD 5.510 ± 0.180 5.316 5.814 1.02 ± 0.03
pnpr@main 5.378 ± 0.036 5.333 5.455 1.00
BENCHMARK_REPORT.json
{
  "results": [
    {
      "command": "pacquet@HEAD",
      "mean": 10.34054619652,
      "stddev": 0.12552550828748366,
      "median": 10.300247367019999,
      "user": 3.40876466,
      "system": 3.2964831599999997,
      "min": 10.22598396252,
      "max": 10.64406365952,
      "times": [
        10.46082312152,
        10.64406365952,
        10.24921724452,
        10.31238400252,
        10.28126063352,
        10.332689287520001,
        10.351150997520001,
        10.259778324520001,
        10.22598396252,
        10.28811073152
      ]
    },
    {
      "command": "pacquet@main",
      "mean": 10.351253402720001,
      "stddev": 0.16860990144668894,
      "median": 10.27619532252,
      "user": 3.3936314599999995,
      "system": 3.2911889599999995,
      "min": 10.213062223520001,
      "max": 10.746234582520001,
      "times": [
        10.39147709052,
        10.28424158652,
        10.33563253952,
        10.24854075352,
        10.26814905852,
        10.746234582520001,
        10.24289589052,
        10.213062223520001,
        10.53610383952,
        10.24619646252
      ]
    },
    {
      "command": "pnpr@HEAD",
      "mean": 5.510274041320001,
      "stddev": 0.17986479937444236,
      "median": 5.4402478500199996,
      "user": 2.66175056,
      "system": 2.9823786599999993,
      "min": 5.31562945452,
      "max": 5.81442244352,
      "times": [
        5.31562945452,
        5.81442244352,
        5.4363199795199995,
        5.36073406552,
        5.61727553452,
        5.62845089252,
        5.36047478052,
        5.44417572052,
        5.75657723252,
        5.368680309519999
      ]
    },
    {
      "command": "pnpr@main",
      "mean": 5.378148609919999,
      "stddev": 0.035832109154349194,
      "median": 5.36958291802,
      "user": 2.67751176,
      "system": 3.0064126599999996,
      "min": 5.333265186519999,
      "max": 5.4547792265199995,
      "times": [
        5.41624216552,
        5.4547792265199995,
        5.36510587452,
        5.3580752795199995,
        5.36902267052,
        5.3414058965199995,
        5.37014316552,
        5.333265186519999,
        5.38653797752,
        5.38690865652
      ]
    }
  ]
}

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

Command Mean [ms] Min [ms] Max [ms] Relative
pacquet@HEAD 648.6 ± 10.6 633.9 666.9 1.00
pacquet@main 682.9 ± 23.7 647.7 725.8 1.05 ± 0.04
pnpr@HEAD 779.1 ± 59.7 738.4 937.5 1.20 ± 0.09
pnpr@main 762.1 ± 25.4 741.1 820.8 1.18 ± 0.04
BENCHMARK_REPORT.json
{
  "results": [
    {
      "command": "pacquet@HEAD",
      "mean": 0.6485593264,
      "stddev": 0.010593296596512234,
      "median": 0.6475796572000001,
      "user": 0.37805652,
      "system": 1.3250590599999998,
      "min": 0.6339012477,
      "max": 0.6669440347000001,
      "times": [
        0.6459008957000001,
        0.6339012477,
        0.6397647297000001,
        0.6669440347000001,
        0.6608116457000001,
        0.6378168537000001,
        0.6440539167,
        0.6492584187,
        0.6578225837,
        0.6493189377
      ]
    },
    {
      "command": "pacquet@main",
      "mean": 0.6828608615000001,
      "stddev": 0.02373925823866274,
      "median": 0.6884915022,
      "user": 0.39452331999999996,
      "system": 1.3434643599999998,
      "min": 0.6476973397000001,
      "max": 0.7258132117,
      "times": [
        0.6584607347000001,
        0.6941471277000001,
        0.7258132117,
        0.6625860957,
        0.6657521727000001,
        0.6996945437000001,
        0.6871243367000001,
        0.6974743847000001,
        0.6476973397000001,
        0.6898586677
      ]
    },
    {
      "command": "pnpr@HEAD",
      "mean": 0.779135398,
      "stddev": 0.05967082242868055,
      "median": 0.7613796402000002,
      "user": 0.3972641199999999,
      "system": 1.3412967599999999,
      "min": 0.7383664097000001,
      "max": 0.9375292297000001,
      "times": [
        0.7601182217000001,
        0.7383664097000001,
        0.8108939847000001,
        0.7734127767000001,
        0.7437579157,
        0.9375292297000001,
        0.7741589057000001,
        0.7626410587000001,
        0.7404816727000001,
        0.7499938047000001
      ]
    },
    {
      "command": "pnpr@main",
      "mean": 0.7620816541000001,
      "stddev": 0.025353917785883435,
      "median": 0.7515323092000001,
      "user": 0.38522631999999996,
      "system": 1.3275770599999999,
      "min": 0.7411409137,
      "max": 0.8208050117000001,
      "times": [
        0.7890520557,
        0.7631550837000001,
        0.7528519407,
        0.7685706907000001,
        0.7411409137,
        0.8208050117000001,
        0.7492691717000001,
        0.7502126777000001,
        0.7426396627,
        0.7431193327000001
      ]
    }
  ]
}

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

Command Mean [s] Min [s] Max [s] Relative
pacquet@HEAD 9.294 ± 0.032 9.253 9.344 1.83 ± 0.02
pacquet@main 9.275 ± 0.044 9.195 9.353 1.83 ± 0.02
pnpr@HEAD 5.076 ± 0.048 5.023 5.176 1.00
pnpr@main 5.134 ± 0.094 5.046 5.343 1.01 ± 0.02
BENCHMARK_REPORT.json
{
  "results": [
    {
      "command": "pacquet@HEAD",
      "mean": 9.29382552202,
      "stddev": 0.03170233175717623,
      "median": 9.29529614232,
      "user": 3.6842291999999994,
      "system": 3.27881152,
      "min": 9.25334646732,
      "max": 9.34365095132,
      "times": [
        9.32129344532,
        9.34365095132,
        9.27032691832,
        9.32900986532,
        9.25582554232,
        9.30750361932,
        9.25334646732,
        9.29738518532,
        9.26670612632,
        9.29320709932
      ]
    },
    {
      "command": "pacquet@main",
      "mean": 9.27481105192,
      "stddev": 0.043722580336474005,
      "median": 9.26864548432,
      "user": 3.6938731999999996,
      "system": 3.2891356200000006,
      "min": 9.19508680232,
      "max": 9.35332142832,
      "times": [
        9.27139941432,
        9.29854918032,
        9.19508680232,
        9.30794889132,
        9.25717276132,
        9.30514428832,
        9.26589155432,
        9.23868441632,
        9.35332142832,
        9.25491178232
      ]
    },
    {
      "command": "pnpr@HEAD",
      "mean": 5.07612119282,
      "stddev": 0.04791208708237304,
      "median": 5.0606121773199995,
      "user": 2.3893584,
      "system": 2.77810302,
      "min": 5.02306011632,
      "max": 5.17630563632,
      "times": [
        5.06342550732,
        5.04284613432,
        5.05779884732,
        5.02306011632,
        5.09782333432,
        5.06561769632,
        5.03877736332,
        5.17630563632,
        5.13833499832,
        5.05722229432
      ]
    },
    {
      "command": "pnpr@main",
      "mean": 5.134076823519999,
      "stddev": 0.09357958875001847,
      "median": 5.1029049868200005,
      "user": 2.3942329999999994,
      "system": 2.83025382,
      "min": 5.04572449832,
      "max": 5.34253436732,
      "times": [
        5.08231668132,
        5.12561658532,
        5.12349329232,
        5.06438641932,
        5.07452666432,
        5.34253436732,
        5.23625055632,
        5.04572449832,
        5.07003868532,
        5.1758804853200004
      ]
    }
  ]
}

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

Command Mean [s] Min [s] Max [s] Relative
pacquet@HEAD 1.478 ± 0.020 1.449 1.514 2.11 ± 0.21
pacquet@main 1.465 ± 0.010 1.447 1.477 2.09 ± 0.21
pnpr@HEAD 0.710 ± 0.079 0.678 0.934 1.01 ± 0.15
pnpr@main 0.700 ± 0.069 0.650 0.878 1.00
BENCHMARK_REPORT.json
{
  "results": [
    {
      "command": "pacquet@HEAD",
      "mean": 1.4782305014800001,
      "stddev": 0.019656956217876803,
      "median": 1.47581865078,
      "user": 1.5977086999999999,
      "system": 1.8362029999999998,
      "min": 1.4493193912800002,
      "max": 1.5139760482800002,
      "times": [
        1.47328166228,
        1.4649930342800002,
        1.5139760482800002,
        1.4783556392800001,
        1.4873948722800001,
        1.4862610042800002,
        1.50067466328,
        1.47138591128,
        1.4493193912800002,
        1.45666278828
      ]
    },
    {
      "command": "pacquet@main",
      "mean": 1.4648146019800001,
      "stddev": 0.010264736285625397,
      "median": 1.46616514828,
      "user": 1.6087571,
      "system": 1.8118349999999999,
      "min": 1.44689538128,
      "max": 1.47670514128,
      "times": [
        1.46408503728,
        1.47670514128,
        1.44987199228,
        1.4695719852800002,
        1.44689538128,
        1.47455346528,
        1.46210665428,
        1.4608306642800002,
        1.4682452592800002,
        1.47528043928
      ]
    },
    {
      "command": "pnpr@HEAD",
      "mean": 0.7100981069800001,
      "stddev": 0.07883749464756337,
      "median": 0.6831182977800001,
      "user": 0.34442529999999993,
      "system": 1.3103341999999998,
      "min": 0.67826871328,
      "max": 0.9337099172800001,
      "times": [
        0.9337099172800001,
        0.6932656512800001,
        0.68029876428,
        0.67963261228,
        0.68144664328,
        0.6847899522800001,
        0.67826871328,
        0.68053370128,
        0.69560247328,
        0.69343264128
      ]
    },
    {
      "command": "pnpr@main",
      "mean": 0.6997986452800001,
      "stddev": 0.06941885972008818,
      "median": 0.6742479272799999,
      "user": 0.3386912999999999,
      "system": 1.2721829,
      "min": 0.65019685928,
      "max": 0.87767005428,
      "times": [
        0.7621102602800001,
        0.67165464428,
        0.67721874228,
        0.68032709928,
        0.87767005428,
        0.66915880528,
        0.65019685928,
        0.66887580728,
        0.66393297028,
        0.67684121028
      ]
    }
  ]
}

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

Command Mean [s] Min [s] Max [s] Relative
pacquet@HEAD 5.122 ± 0.027 5.065 5.164 7.38 ± 0.69
pacquet@main 5.114 ± 0.036 5.030 5.147 7.37 ± 0.69
pnpr@HEAD 0.727 ± 0.029 0.703 0.801 1.05 ± 0.11
pnpr@main 0.694 ± 0.065 0.659 0.874 1.00
BENCHMARK_REPORT.json
{
  "results": [
    {
      "command": "pacquet@HEAD",
      "mean": 5.12205450992,
      "stddev": 0.026911162644216398,
      "median": 5.12624642612,
      "user": 1.8208285399999997,
      "system": 2.04073636,
      "min": 5.06539251412,
      "max": 5.16369593612,
      "times": [
        5.13826388112,
        5.16369593612,
        5.11009627212,
        5.13786958012,
        5.12195632112,
        5.06539251412,
        5.130536531120001,
        5.11096119612,
        5.1398561671200005,
        5.10191670012
      ]
    },
    {
      "command": "pacquet@main",
      "mean": 5.113692689719999,
      "stddev": 0.03643199100035146,
      "median": 5.1221285096199995,
      "user": 1.8560067400000002,
      "system": 1.9494806599999996,
      "min": 5.03049607412,
      "max": 5.146956262120001,
      "times": [
        5.11906027812,
        5.0734099091200004,
        5.1451290721200005,
        5.03049607412,
        5.11828661712,
        5.12519674112,
        5.12875039612,
        5.10679499112,
        5.146956262120001,
        5.14284655612
      ]
    },
    {
      "command": "pnpr@HEAD",
      "mean": 0.7269718082200002,
      "stddev": 0.02931412969215391,
      "median": 0.72139363162,
      "user": 0.35265704,
      "system": 1.3211141599999998,
      "min": 0.7026825151200001,
      "max": 0.8013555481200001,
      "times": [
        0.8013555481200001,
        0.71122070412,
        0.7444841861200001,
        0.7035025291200001,
        0.7193977561200001,
        0.7255046851200001,
        0.7066649801200001,
        0.7026825151200001,
        0.72338950712,
        0.73151567112
      ]
    },
    {
      "command": "pnpr@main",
      "mean": 0.6935981485200001,
      "stddev": 0.06468182030188299,
      "median": 0.6727471546200001,
      "user": 0.33925503999999995,
      "system": 1.2730442599999998,
      "min": 0.6586367901200001,
      "max": 0.8743269341200001,
      "times": [
        0.7008642641200001,
        0.6793686211200001,
        0.6604229481200001,
        0.6661078211200001,
        0.8743269341200001,
        0.6825569491200001,
        0.6586367901200001,
        0.6682028481200001,
        0.66954518612,
        0.6759491231200001
      ]
    }
  ]
}

@github-actions

github-actions Bot commented Jun 8, 2026

Copy link
Copy Markdown
Contributor

🐰 Bencher Report

Branchpr/12261
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
9,293.83 ms
(+18.08%)Baseline: 7,870.61 ms
9,444.73 ms
(98.40%)
isolated-linker.fresh-install.cold-cache.hot-store📈 view plot
🚷 view threshold
5,122.05 ms
(+1.99%)Baseline: 5,022.02 ms
6,026.43 ms
(84.99%)
isolated-linker.fresh-install.hot-cache.hot-store📈 view plot
🚷 view threshold
1,478.23 ms
(+4.27%)Baseline: 1,417.71 ms
1,701.25 ms
(86.89%)
isolated-linker.fresh-restore.cold-cache.cold-store📈 view plot
🚷 view threshold
10,340.55 ms
(+6.99%)Baseline: 9,665.28 ms
11,598.33 ms
(89.16%)
isolated-linker.fresh-restore.hot-cache.hot-store📈 view plot
🚷 view threshold
648.56 ms
(-1.40%)Baseline: 657.75 ms
789.30 ms
(82.17%)
🐰 View full continuous benchmarking report in Bencher

@zkochan zkochan force-pushed the chore/update-lockfile branch from b0b1513 to 25353f8 Compare June 9, 2026 07:23
@qodo-free-for-open-source-projects

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

Copy link
Copy Markdown

Code Review by Qodo

🐞 Bugs (2) 📘 Rule violations (0)

Grey Divider


Remediation recommended

1. Runtime version becomes undefined 🐞 Bug ≡ Correctness
Description
pnpm-lock.yaml no longer records packages['node@runtime:26.3.0'].version, so
nameVerFromPkgSnapshot('node@runtime:26.3.0', ...) returns version = undefined (the depPath is
non-semver). That undefined version then flows into lockfile-derived data structures (preferred
versions) and global-virtual-store path formatting that expects a real version string.
Code

pnpm-lock.yaml[R15351-15354]

          - cpu: x64
            os: linux
            libc: musl
-    version: 26.3.0
  hasBin: true
Evidence
The lockfile’s node@runtime:26.3.0 package entry lacks a version field, and deps.path.parse()
only sets version when the depPath’s version is valid semver—runtime:26.3.0 is not. Multiple
core paths (preferred versions collection and global-virtual-store hashing/layout) consume
nameVerFromPkgSnapshot() and treat version as a real string, so the missing field causes
undefined to propagate into those computations.

pnpm-lock.yaml[15236-15354]
lockfile/utils/src/nameVerFromPkgSnapshot.ts[12-22]
deps/path/src/index.ts[120-165]
lockfile/preferred-versions/src/index.ts[35-55]
deps/graph-hasher/src/index.ts[280-286]
deps/graph-builder/src/iteratePkgsForVirtualStore.ts[51-85]
deps/graph-builder/src/lockfileToDepGraph.ts[187-213]
engine/runtime/node-resolver/src/index.ts[58-81]

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 entry for `node@runtime:26.3.0` is missing the `version: 26.3.0` field. For runtime depPaths, `@pnpm/deps.path.parse()` does not produce a semver `version` (it yields `nonSemverVersion: 'runtime:26.3.0'`), so `nameVerFromPkgSnapshot()` returns `version = undefined`. This leaks into components that treat `version` as a stable string (e.g. preferred-versions keys and global-virtual-store path formatting).
### Issue Context
- `nameVerFromPkgSnapshot()` prefers `pkgSnapshot.version` and otherwise falls back to `dp.parse(depPath).version`.
- For `node@runtime:<ver>`, `dp.parse()` does **not** set `version` because the portion after `@` is `runtime:<ver>` (non-semver).
### Fix Focus Areas
- pnpm-lock.yaml[15236-15354]
- lockfile/utils/src/nameVerFromPkgSnapshot.ts[12-22]
- deps/path/src/index.ts[120-165]
### Suggested fix
Choose one (A is quickest for this PR; B is more robust):
1) **(A) Lockfile fix:** Re-add `version: 26.3.0` under `packages: node@runtime:26.3.0` (so lockfile readers can derive a semver version).
2) **(B) Code hardening:** Update `nameVerFromPkgSnapshot()` to recognize runtime depPaths:
- If `pkgSnapshot.version` is missing and `pkgInfo.nonSemverVersion` starts with `runtime:`, strip the prefix and use the remainder as `version` when it is valid semver.
If you pick (B), keep (A) as well if your lockfile writer intends to preserve the `version` field for non-registry/runtime packages.

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


2. Compile Node version drift 🐞 Bug ☼ Reliability
Description
compile-only now runs pnx node@runtime:^26.3.0, and pnx is a pnpm dlx shim, so the selected
Node runtime can float to newer compatible versions over time. This makes typechecking/compilation
less reproducible across machines and across time without any repo change.
Code

package.json[20]

+    "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
The script change introduces a caret range into a pnx invocation. Since pnx is implemented as
pnpm dlx, it resolves the requested package at run time, so a range spec inherently allows drift
in the chosen Node version.

package.json[17-22]
pnpm/artifacts/exe/pnx[1-2]

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` runs `pnx node@runtime:^26.3.0 ...`. Because `pnx` is `pnpm dlx`, it resolves and downloads at execution time, and the caret range can select a different Node 26.x release later. This reduces determinism of compilation/typechecking.
### Issue Context
- `pnx` is a thin wrapper over `pnpm dlx`.
- `dlx` is designed for ephemeral, dynamically-resolved executions.
### Fix Focus Areas
- package.json[17-22]
- pnpm/artifacts/exe/pnx[1-2]
### Suggested fix
Pin the runtime in `compile-only` back to an exact version (e.g. `node@runtime:26.3.0`), or otherwise ensure the Node version used for typechecking is derived from a pinned source (e.g. a lockfile-pinned runtime dependency and a command path that honors it, rather than `dlx`).

ⓘ 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 6ef8897

Results up to commit 1fd4de7


🐞 Bugs (2) 📘 Rule violations (0)


Remediation recommended
1. Runtime version becomes undefined 🐞 Bug ≡ Correctness
Description
pnpm-lock.yaml no longer records packages['node@runtime:26.3.0'].version, so
nameVerFromPkgSnapshot('node@runtime:26.3.0', ...) returns version = undefined (the depPath is
non-semver). That undefined version then flows into lockfile-derived data structures (preferred
versions) and global-virtual-store path formatting that expects a real version string.
Code

pnpm-lock.yaml[R15351-15354]

           - cpu: x64
             os: linux
             libc: musl
-    version: 26.3.0
   hasBin: true
Evidence
The lockfile’s node@runtime:26.3.0 package entry lacks a version field, and deps.path.parse()
only sets version when the depPath’s version is valid semver—runtime:26.3.0 is not. Multiple
core paths (preferred versions collection and global-virtual-store hashing/layout) consume
nameVerFromPkgSnapshot() and treat version as a real string, so the missing field causes
undefined to propagate into those computations.

pnpm-lock.yaml[15236-15354]
lockfile/utils/src/nameVerFromPkgSnapshot.ts[12-22]
deps/path/src/index.ts[120-165]
lockfile/preferred-versions/src/index.ts[35-55]
deps/graph-hasher/src/index.ts[280-286]
deps/graph-builder/src/iteratePkgsForVirtualStore.ts[51-85]
deps/graph-builder/src/lockfileToDepGraph.ts[187-213]
engine/runtime/node-resolver/src/index.ts[58-81]

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 entry for `node@runtime:26.3.0` is missing the `version: 26.3.0` field. For runtime depPaths, `@pnpm/deps.path.parse()` does not produce a semver `version` (it yields `nonSemverVersion: 'runtime:26.3.0'`), so `nameVerFromPkgSnapshot()` returns `version = undefined`. This leaks into components that treat `version` as a stable string (e.g. preferred-versions keys and global-virtual-store path formatting).
### Issue Context
- `nameVerFromPkgSnapshot()` prefers `pkgSnapshot.version` and otherwise falls back to `dp.parse(depPath).version`.
- For `node@runtime:<ver>`, `dp.parse()` does **not** set `version` because the portion after `@` is `runtime:<ver>` (non-semver).
### Fix Focus Areas
- pnpm-lock.yaml[15236-15354]
- lockfile/utils/src/nameVerFromPkgSnapshot.ts[12-22]
- deps/path/src/index.ts[120-165]
### Suggested fix
Choose one (A is quickest for this PR; B is more robust):
1) **(A) Lockfile fix:** Re-add `version: 26.3.0` under `packages: node@runtime:26.3.0` (so lockfile readers can derive a semver version).
2) **(B) Code hardening:** Update `nameVerFromPkgSnapshot()` to recognize runtime depPaths:
 - If `pkgSnapshot.version` is missing and `pkgInfo.nonSemverVersion` starts with `runtime:`, strip the prefix and use the remainder as `version` when it is valid semver.
If you pick (B), keep (A) as well if your lockfile writer intends to preserve the `version` field for non-registry/runtime packages.

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


2. Compile Node version drift 🐞 Bug ☼ Reliability
Description
compile-only now runs pnx node@runtime:^26.3.0, and pnx is a pnpm dlx shim, so the selected
Node runtime can float to newer compatible versions over time. This makes typechecking/compilation
less reproducible across machines and across time without any repo change.
Code

package.json[20]

+    "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
The script change introduces a caret range into a pnx invocation. Since pnx is implemented as
pnpm dlx, it resolves the requested package at run time, so a range spec inherently allows drift
in the chosen Node version.

package.json[17-22]
pnpm/artifacts/exe/pnx[1-2]

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` runs `pnx node@runtime:^26.3.0 ...`. Because `pnx` is `pnpm dlx`, it resolves and downloads at execution time, and the caret range can select a different Node 26.x release later. This reduces determinism of compilation/typechecking.
### Issue Context
- `pnx` is a thin wrapper over `pnpm dlx`.
- `dlx` is designed for ephemeral, dynamically-resolved executions.
### Fix Focus Areas
- package.json[17-22]
- pnpm/artifacts/exe/pnx[1-2]
### Suggested fix
Pin the runtime in `compile-only` back to an exact version (e.g. `node@runtime:26.3.0`), or otherwise ensure the Node version used for typechecking is derived from a pinned source (e.g. a lockfile-pinned runtime dependency and a command path that honors it, rather than `dlx`).

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


Results up to commit 25353f8


🐞 Bugs (2) 📘 Rule violations (0)


Remediation recommended
1. Runtime version becomes undefined 🐞 Bug ≡ Correctness
Description
pnpm-lock.yaml no longer records packages['node@runtime:26.3.0'].version, so
nameVerFromPkgSnapshot('node@runtime:26.3.0', ...) returns version = undefined (the depPath is
non-semver). That undefined version then flows into lockfile-derived data structures (preferred
versions) and global-virtual-store path formatting that expects a real version string.
Code

pnpm-lock.yaml[R15351-15354]

            - cpu: x64
              os: linux
              libc: musl
-    version: 26.3.0
    hasBin: true
Evidence
The lockfile’s node@runtime:26.3.0 package entry lacks a version field, and deps.path.parse()
only sets version when the depPath’s version is valid semver—runtime:26.3.0 is not. Multiple
core paths (preferred versions collection and global-virtual-store hashing/layout) consume
nameVerFromPkgSnapshot() and treat version as a real string, so the missing field causes
undefined to propagate into those computations.

pnpm-lock.yaml[15236-15354]
lockfile/utils/src/nameVerFromPkgSnapshot.ts[12-22]
deps/path/src/index.ts[120-165]
lockfile/preferred-versions/src/index.ts[35-55]
deps/graph-hasher/src/index.ts[280-286]
deps/graph-builder/src/iteratePkgsForVirtualStore.ts[51-85]
deps/graph-builder/src/lockfileToDepGraph.ts[187-213]
engine/runtime/node-resolver/src/index.ts[58-81]

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 entry for `node@runtime:26.3.0` is missing the `version: 26.3.0` field. For runtime depPaths, `@pnpm/deps.path.parse()` does not produce a semver `version` (it yields `nonSemverVersion: 'runtime:26.3.0'`), so `nameVerFromPkgSnapshot()` returns `version = undefined`. This leaks into components that treat `version` as a stable string (e.g. preferred-versions keys and global-virtual-store path formatting).

### Issue Context
- `nameVerFromPkgSnapshot()` prefers `pkgSnapshot.version` and otherwise falls back to `dp.parse(depPath).version`.
- For `node@runtime:<ver>`, `dp.parse()` does **not** set `version` because the portion after `@` is `runtime:<ver>` (non-semver).

### Fix Focus Areas
- pnpm-lock.yaml[15236-15354]
- lockfile/utils/src/nameVerFromPkgSnapshot.ts[12-22]
- deps/path/src/index.ts[120-165]

### Suggested fix
Choose one (A is quickest for this PR; B is more robust):
1) **(A) Lockfile fix:** Re-add `version: 26.3.0` under `packages: node@runtime:26.3.0` (so lockfile readers can derive a semver version).
2) **(B) Code hardening:** Update `nameVerFromPkgSnapshot()` to recognize runtime depPaths:
  - If `pkgSnapshot.version` is missing and `pkgInfo.nonSemverVersion` starts with `runtime:`, strip the prefix and use the remainder as `version` when it is valid semver.

If you pick (B), keep (A) as well if your lockfile writer intends to preserve the `version` field for non-registry/runtime packages.

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


2. Compile Node version drift 🐞 Bug ☼ Reliability
Description
compile-only now runs pnx node@runtime:^26.3.0, and pnx is a pnpm dlx shim, so the selected
Node runtime can float to newer compatible versions over time. This makes typechecking/compilation
less reproducible across machines and across time without any repo change.
Code

package.json[20]

+    "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
The script change introduces a caret range into a pnx invocation. Since pnx is implemented as
pnpm dlx, it resolves the requested package at run time, so a range spec inherently allows drift
in the chosen Node version.

package.json[17-22]
pnpm/artifacts/exe/pnx[1-2]

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` runs `pnx node@runtime:^26.3.0 ...`. Because `pnx` is `pnpm dlx`, it resolves and downloads at execution time, and the caret range can select a different Node 26.x release later. This reduces determinism of compilation/typechecking.

### Issue Context
- `pnx` is a thin wrapper over `pnpm dlx`.
- `dlx` is designed for ephemeral, dynamically-resolved executions.

### Fix Focus Areas
- package.json[17-22]
- pnpm/artifacts/exe/pnx[1-2]

### Suggested fix
Pin the runtime in `compile-only` back to an exact version (e.g. `node@runtime:26.3.0`), or otherwise ensure the Node version used for typechecking is derived from a pinned source (e.g. a lockfile-pinned runtime dependency and a command path that honors it, rather than `dlx`).

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


Qodo Logo

@zkochan zkochan force-pushed the chore/update-lockfile branch from 25353f8 to 1fd4de7 Compare June 10, 2026 07:39
@qodo-free-for-open-source-projects

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

Copy link
Copy Markdown

Code review by qodo was updated up to the latest commit 1fd4de7

@github-actions

Copy link
Copy Markdown
Contributor

🐰 Bencher Report

Branchpr/12261
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
5,076.12 ms
isolated-linker.fresh-install.cold-cache.hot-store📈 view plot
⚠️ NO THRESHOLD
726.97 ms
isolated-linker.fresh-install.hot-cache.hot-store📈 view plot
⚠️ NO THRESHOLD
710.10 ms
isolated-linker.fresh-restore.cold-cache.cold-store📈 view plot
⚠️ NO THRESHOLD
5,510.27 ms
isolated-linker.fresh-restore.hot-cache.hot-store📈 view plot
⚠️ NO THRESHOLD
779.14 ms
🐰 View full continuous benchmarking report in Bencher

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

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

Copy link
Copy Markdown

Code review by qodo was updated up to the latest commit 6ef8897

@zkochan

zkochan commented Jun 10, 2026

Copy link
Copy Markdown
Member Author

@coderabbitai approve

@coderabbitai

coderabbitai Bot commented Jun 10, 2026

Copy link
Copy Markdown
✅ Action performed

Comments resolved and changes approved.

@zkochan zkochan merged commit d2125b8 into main Jun 10, 2026
12 checks passed
@zkochan zkochan deleted the chore/update-lockfile branch June 10, 2026 12:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant