chore: update lockfile, Node.js, pnpm, and pacquet versions#12421
Conversation
Code Review by Qodo
1.
|
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (1)
📝 WalkthroughWalkthroughTwo version bumps across two config files: ChangesToolchain Version Bumps
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~2 minutes Possibly related PRs
Suggested labels
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
PR Summary by QodoChore: refresh lockfile; bump Node 26.x, pnpm 11.7, and pacquet WalkthroughsDescription• Bump Node runtime constraint to ^26.3.0 for dev tooling and scripts. • Upgrade pnpm to 11.7.0 and refresh the pnpm lockfile. • Update @pnpm/pacquet config dependency to 0.11.7 across workspace config. Diagramgraph TD
CI["CI / workflows"] --> PJ["package.json"] --> WS["pnpm-workspace.yaml"] --> LOCK["pnpm-lock.yaml"]
PJ --> NODE(("Node.js ^26.3.0"))
PJ --> PNPM(("pnpm 11.7.0"))
WS --> PAC(("@pnpm/pacquet 0.11.7"))
High-Level AssessmentThe following are alternative approaches to this PR: 1. Keep Node pinned to an exact patch version
2. Allow Node range but pin tooling invocation to a specific runtime
Recommendation: The current approach (moving Node from an exact 26.3.0 pin to ^26.3.0) is reasonable if the project intentionally tracks the latest compatible 26.x runtime. If determinism is a priority (e.g., to reduce CI variability), consider reverting to an exact patch pin for Node while still upgrading pnpm/pacquet and refreshing the lockfile. File ChangesOther (3)
|
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (1)
pnpm-workspace.yaml (1)
353-353: Behavioral change: pacquet 0.11.7 enables full resolving installs.The bump from
0.11.4to0.11.7crosses a feature-gate threshold. Perinstalling/commands/src/runPacquet.ts:270-275, pacquet >= 0.11.7 supports full resolving installs, while earlier versions stay on pnpm's resolve-then-materialize path. This means non-frozen plain installs will now delegate both resolution and materialization to pacquet instead of only materialization.This is a significant change in the install code path. Ensure the change is intentional and that pacquet 0.11.7's resolving installs behavior has been tested in the repository's install workflows.
🤖 Prompt for 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. In `@pnpm-workspace.yaml` at line 353, The pacquet version bump from 0.11.4 to 0.11.7 activates full resolving installs behavior as determined by the version check logic in runPacquet.ts, which means non-frozen plain installs will now use pacquet for both resolution and materialization instead of just materialization. Verify this behavioral change in install workflows is intentional by reviewing the runPacquet.ts version gate logic (around lines 270-275) to confirm the threshold, then test and document that pacquet 0.11.7's resolving installs behavior works correctly in your repository's standard install scenarios to ensure the change does not introduce regressions.
🤖 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 65: The packageManager field is set to pnpm version 11.7.0, which does
not exist. Update the packageManager field in package.json to use pnpm@11.6.0,
which is the latest stable release in the pnpm 11 series as of June 2026. Note
that the comment indicates this version specification appears in multiple places
in package.json and all occurrences should be updated to the correct version.
- Line 21: The meta-updater cannot sync semver ranges because the regex at
`.meta-updater/src/index.ts:312` used by syncNodeRuntimeInScripts() only matches
exact versions like `node@runtime:[\d.]+` and not semver operators like `^`.
Revert both line 21 and line 74 in package.json from the semver range `^26.3.0`
back to the exact version `26.3.0` to keep the Node.js runtime version pinned
and in sync across devEngines and scripts, or alternatively update the
meta-updater regex to handle semver ranges like `^` if you need semver
flexibility.
In `@pnpm-workspace.yaml`:
- Line 353: Update the `@pnpm/pacquet` version in pnpm-workspace.yaml from 0.11.7
to a publicly available and security-patched release. The specified version
0.11.7 is not a published npm release; verify and update to the latest stable
public version (0.2.3 or newer if available) or ensure the current version
includes the patch for security advisory GHSA-3qhv-2rgh-x77r, which addresses
environment variable expansion vulnerabilities in repository-controlled
configuration files. If an internal development version is intentionally being
used, document confirmation that the patch disabling environment variable
expansion in repository-controlled sources is included.
---
Nitpick comments:
In `@pnpm-workspace.yaml`:
- Line 353: The pacquet version bump from 0.11.4 to 0.11.7 activates full
resolving installs behavior as determined by the version check logic in
runPacquet.ts, which means non-frozen plain installs will now use pacquet for
both resolution and materialization instead of just materialization. Verify this
behavioral change in install workflows is intentional by reviewing the
runPacquet.ts version gate logic (around lines 270-275) to confirm the
threshold, then test and document that pacquet 0.11.7's resolving installs
behavior works correctly in your repository's standard install scenarios to
ensure the change does not introduce regressions.
🪄 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: 3180c451-5b65-4f61-a80e-93d167447e97
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (2)
package.jsonpnpm-workspace.yaml
| "typescript": "catalog:" | ||
| }, | ||
| "packageManager": "pnpm@11.6.0", | ||
| "packageManager": "pnpm@11.7.0", |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
pnpm 11.7.0 release notes changelog dependency management commands
💡 Result:
As of today, June 15, 2026, pnpm version 11.7.0 has not been released. The most recent stable release in the pnpm 11 series is version 11.6.0, which was released on June 11, 2026 [1]. For context, pnpm 11 is the current major version of the package manager, introduced on April 28, 2026 [2][3]. Key features and changes in the pnpm 11 series include: - Requirement of Node.js 22 or newer, with pnpm itself transitioning to pure ESM [3]. - Enhanced security defaults, such as a default minimum release age for new packages (to protect against supply chain attacks) and stricter dependency build settings [2][3]. - A transition to a native implementation for package publishing commands (e.g., publish, login, logout, unpublish), removing the reliance on the npm CLI fallback [3]. - A new SQLite-backed store index (store v11) for improved performance [3]. - Global package isolation, where global installs no longer share a virtual store, preventing dependency conflicts [3]. Official changelogs and release notes for all pnpm versions can be found in the official GitHub repository at https://github.com/pnpm/pnpm/blob/main/pnpm/CHANGELOG.md [4].
Citations:
- 1: https://github.com/pnpm/pnpm/releases/tag/v11.6.0
- 2: https://github.com/pnpm/pnpm/releases/tag/v11.0.0
- 3: https://pnpm.io/blog/releases/11.0
- 4: https://github.com/pnpm/pnpm/blob/main/pnpm/CHANGELOG.md
🌐 Web query:
pnpm 11.7.0 security vulnerabilities CVE
💡 Result:
As of June 15, 2026, there are no security vulnerabilities specifically assigned to pnpm version 11.7.0 [1]. Several security advisories have been issued for the pnpm 11.x release line, but they have been addressed in subsequent patch releases. Specifically, relevant vulnerabilities in the 11.x line include: * CVE-2026-48995: Affects versions >= 11.0.0 and < 11.0.7, where GitHub git dependency tarball hashes were not stored in the lockfile [2]. This was patched in version 11.0.7 [2]. * CVE-2026-50016: A path traversal vulnerability affecting versions >= 11.0.0 and < 11.4.0, which allowed project path overrides [3]. This was patched in version 11.4.0 [3]. * CVE-2026-50017: A credential exposure vulnerability affecting versions >= 11.0.0 and < 11.4.0, where unscoped npm credentials could be sent to unauthorized registries [4]. This was patched in version 11.4.0 [4]. * AIKIDO-2026-10970 (Insufficient policy enforcement): Affected versions 11.0.0 through 11.1.1, involving metadata caching issues and potential CPU exhaustion [5]. This was patched in version 11.1.2 [5]. Because pnpm 11.7.0 was released after these security patches, it is not affected by these specific vulnerabilities [1]. Users are encouraged to always use the latest available version of pnpm to ensure all known security patches are included [1].
Citations:
- 1: https://security.snyk.io/package/npm/pnpm
- 2: GHSA-hg3w-7f8c-63hp
- 3: GHSA-hwx4-2j3j-g496
- 4: GHSA-cjhr-43r9-cfmw
- 5: https://intel.aikido.dev/cve/AIKIDO-2026-10970
Use pnpm 11.6.0 instead—version 11.7.0 does not exist. As of June 15, 2026, the latest stable release in the pnpm 11 series is 11.6.0 (released June 11, 2026). Update package.json lines 65 and 69 to reference pnpm@11.6.0.
🤖 Prompt for 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.
In `@package.json` at line 65, The packageManager field is set to pnpm version
11.7.0, which does not exist. Update the packageManager field in package.json to
use pnpm@11.6.0, which is the latest stable release in the pnpm 11 series as of
June 2026. Note that the comment indicates this version specification appears in
multiple places in package.json and all occurrences should be updated to the
correct version.
|
|
||
| configDependencies: | ||
| '@pnpm/pacquet': 0.11.4 | ||
| '@pnpm/pacquet': 0.11.7 |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
pacquet 0.11.7 security vulnerabilities CVE
💡 Result:
There is no CVE specifically assigned to the pacquet package manager version 0.11.7. However, pacquet was identified as an affected component in a security advisory regarding environmental variable expansion [1]. The primary security-related issue involving pacquet is: Environmental Variable Expansion Vulnerability (GHSA-3qhv-2rgh-x77r): Pacquet, along with pnpm, was identified as affected by a vulnerability where environment variable placeholders (e.g., ${ENV_VAR}) in repository-level.npmrc or pnpm-workspace.yaml files could be expanded into registry request destinations or authentication headers [1]. This could allow a malicious repository to exfiltrate environment secrets to an attacker-controlled registry [1]. This is tracked under CWE-201, CWE-200, and CWE-522 [1]. It is important to distinguish this from CVE-2026-9496, which is a Denial of Service (DoS) vulnerability affecting the npm package pacote (versions 11.2.7 and later), not pacquet [2][3][4][5]. Pacote is a different library used within the Node.js ecosystem for fetching packages and is not the same as the pacquet package manager [2][4].
Citations:
- 1: GHSA-3qhv-2rgh-x77r
- 2: https://app.opencve.io/cve/CVE-2026-9496
- 3: https://app.opencve.io/cve/?product=pacote&vendor=npmjs
- 4: https://www.sentinelone.com/vulnerability-database/cve-2026-9496/
- 5: https://radar.offseq.com/threat/cve-2026-9496-denial-of-service-dos-in-pacote-27dd65a5
🌐 Web query:
@pnpm/pacquet 0.11.7 npm security advisories
💡 Result:
As of June 15, 2026, there is no specific security advisory issued for a version named "0.11.7" of @pnpm/pacquet. Pacquet is the Rust-based rewrite of pnpm, and its versioning, security posture, and vulnerability disclosures are managed in direct coordination with the core pnpm project [1][2][3]. Recent security vulnerabilities impacting the pnpm ecosystem—which include the pacquet implementation—have been disclosed via official GitHub Security Advisories for the main pnpm repository [4][5]. Relevant recent advisories and security hardening measures include: 1. GHSA-3qhv-2rgh-x77r (CAND-PNPM-122): This advisory addresses a vulnerability where repository-controlled.npmrc and pnpm-workspace.yaml files could expand environment variable placeholders into registry request destinations and credentials, potentially leaking secrets [4]. Pacquet was identified as an affected component and was patched to prevent this expansion [4]. 2. GHSA-4gxm-v5v7-fqc4 (CAND-PNPM-085): This advisory addresses the need to harden bin name validation by explicitly rejecting reserved names (e.g., ".", "..") that could otherwise resolve to unsafe paths [5]. Pacquet's Rust-based bin resolver was updated to mirror the validation logic used in pnpm's TypeScript implementation [5]. 3. Security Hardening (pnpm v11.5.3): In June 2026, pnpm introduced mandatory verification of npm registry signatures for its own binaries and the @pacquet/ platform-specific binaries [6][7]. This mechanism ensures that a compromised or malicious registry cannot supply a tampered binary for pacquet, as the system will now block execution if the signature does not verify [6][7]. Because pacquet is an experimental install backend for pnpm and is frequently updated in lockstep with the core pnpm repository, users should monitor the main pnpm security advisories page for the most accurate and up-to-date information regarding vulnerabilities affecting the ecosystem [4][1]. [4][6][5][7]
Citations:
- 1: https://pnpm.io/blog/releases/11.2
- 2: https://npmx.dev/package/pacquet
- 3: https://npmx.dev/package/@pnpm/pacquet
- 4: GHSA-3qhv-2rgh-x77r
- 5: fix(bins.resolver): reject reserved manifest bin names (GHSA-4gxm-v5v7-fqc4) #12289
- 6: fix(security): verify npm registry signature before spawning a package-manager binary #12292
- 7: https://newreleases.io/project/github/pnpm/pnpm/release/v11.5.3
🌐 Web query:
GHSA-3qhv-2rgh-x77r pacquet patch version fix
💡 Result:
The security vulnerability GHSA-3qhv-2rgh-x77r involves the improper expansion of environment variable placeholders (${ENV_VAR}) within repository-controlled configuration files (specifically .npmrc and pnpm-workspace.yaml). This could allow a malicious repository to exfiltrate sensitive environment secrets to an attacker-controlled registry during package installation [1][2][3]. To address this, pnpm and its Rust-based implementation, pacquet, have been updated to treat environment variable expansion as "trust-aware." As of pnpm versions 10.34.2 and 11.5.3, these placeholders are no longer expanded when they appear in sensitive fields—such as registry URLs, proxy settings, and authentication credentials—within repository-controlled configuration files [1][2][3][4]. If you are using pacquet or pnpm and encounter issues due to this change, you should migrate your configuration to a "trusted" source, such as your user-level ~/.npmrc file, global configuration, or CLI options, where environment variable expansion remains supported [3][5][4]. Top results: [1][2][3][4]
Citations:
- 1: https://pnpm.io/blog
- 2: GHSA-3qhv-2rgh-x77r
- 3: https://pnpm.io/blog/2026/06/11/env-variables-in-repository-npmrc
- 4: https://rwatcher.yadoc.fr/components/397561b1-1dae-485c-9c98-04e8814675c5/38b158b2-16da-4512-8666-bf2cf257380d
- 5: https://pnpm.io/npmrc
🌐 Web query:
pacquet 0.11.7 release date changelog environment variable
💡 Result:
Pacquet is an ongoing project serving as the official Rust-based rewrite of the pnpm package manager [1]. As of June 15, 2026, there is no single publicly released version named 0.11.7. Development is tracked primarily through the pnpm/pacquet GitHub repository [2][3][4][5]. Regarding your specific areas of interest: Release Information There is no official release manifest for a 0.11.7 version [1]. Recent development activity indicates that pnpm has begun delegating resolution tasks to pacquet versions 0.11 and higher [3]. Because pacquet is still in active development and not yet production-ready, it does not follow a traditional, public-facing stable release cadence like standard npm packages [1]. Environment Variables Pacquet has specific handling for environment variables related to configuration and security [6]: - Trusted configuration sources, including user-level.npmrc files, CLI arguments, and actual environment variables, continue to support environment variable expansion (e.g., ${ENV_VAR}) for registry configuration and authentication [6]. - Security restrictions have been implemented to prevent project-level.npmrc files and pnpm-workspace.yaml files from expanding environment variable placeholders. This is a security measure to prevent potential leakage of environment secrets to unauthorized registries during dependency resolution [6]. For the most accurate and up-to-date information on the codebase, you should refer to the official pnpm/pacquet repository on GitHub, as it remains the primary source for the project's roadmap and ongoing development status [1][5].
Citations:
- 1: https://npmx.dev/package/pacquet
- 2: Replace env-variable mutation in
crates/config(pacquet_config) tests with dependency injection pacquet#343 - 3: feat(installing): delegate resolution to pacquet >= 0.11.7 when configured #12210
- 4: supportedArchitectures config + --cpu/--os/--libc CLI flags + real libc detection (#434 slice 2) pacquet#453
- 5: Install runtime dependencies (
node@runtime:,deno@runtime:,bun@runtime:) frompnpm-lock.yamlpacquet#437 - 6: GHSA-3qhv-2rgh-x77r
🏁 Script executed:
cat -n pnpm-workspace.yaml | sed -n '345,360p'Repository: pnpm/pnpm
Length of output: 377
🌐 Web query:
pacquet npm releases latest version 0.11
💡 Result:
As of June 15, 2026, pacquet—the official pnpm rewrite in Rust—is an active development project and has reached version 0.11+ in the context of its integration with pnpm [1]. While individual standalone packages (such as pacquet or @pnpm/pacquet on registries) may show version numbers like 0.2.x [2][3], pnpm has specifically introduced configuration requirements for pacquet version 0.11 or higher to enable the delegation of installation resolution [1]. Specifically, pnpm version 11.2.2 and subsequent releases include an experimental feature where pnpm install can delegate the materialization phase to the pacquet binary when pacquet is added to configDependencies in pnpm-workspace.yaml [4]. Development efforts are currently focused on reaching feature parity with pnpm, including support for commands like update and handling various dependency types [5][1][6][7]. It remains an experimental, non-production-ready tool [2][3].
Citations:
- 1: feat(installing): delegate resolution to pacquet >= 0.11.7 when configured #12210
- 2: https://npmx.dev/package/pacquet
- 3: https://npmx.dev/package/@pnpm/pacquet
- 4: https://github.com/pnpm/pnpm/releases/tag/v11.2.2
- 5: feat(pacquet): implement the
updatecommand #12102 - 6: https://github.com/pnpm/pacquet/issues/299
- 7: pacquet: support remote (non-registry) https-tarball direct dependencies (prerequisite for #12001 integrity parity) #12053
🌐 Web query:
@pnpm/pacquet versions npm registry available
💡 Result:
@pnpm/pacquet versions available on the npm registry (as of 2026-06-15): - Latest published version: 0.2.3 (May 21, 2026) [1] Notes / limitations: - The most authoritative “version list” would come from the package’s npm registry document at https://registry.npmjs.org/@pnpm/pacquet, but it wasn’t returned in the search results I could access here. So I can only confirm the latest version from the sources retrieved above, not enumerate every historical version number. [1] Sources: - npm package page summary for @pnpm/pacquet, including the “latest” version and publish date. [1] If you want, I can do a follow-up lookup specifically on https://registry.npmjs.org/@pnpm/pacquet to enumerate the full version list.
Citations:
Clarify pacquet version and verify security advisory status.
Pacquet 0.11.7 is not a published npm release; the latest public version of @pnpm/pacquet is 0.2.3 (May 21, 2026). If this is an internal development version, confirm it includes the patch for GHSA-3qhv-2rgh-x77r—a known advisory where environment variable placeholders in repository-controlled .npmrc and pnpm-workspace.yaml files could exfiltrate secrets to attacker-controlled registries. This vulnerability has been patched in pnpm v10.34.2, v11.5.3, and corresponding pacquet releases by disabling environment variable expansion in repository-controlled configuration sources.
🤖 Prompt for 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.
In `@pnpm-workspace.yaml` at line 353, Update the `@pnpm/pacquet` version in
pnpm-workspace.yaml from 0.11.7 to a publicly available and security-patched
release. The specified version 0.11.7 is not a published npm release; verify and
update to the latest stable public version (0.2.3 or newer if available) or
ensure the current version includes the patch for security advisory
GHSA-3qhv-2rgh-x77r, which addresses environment variable expansion
vulnerabilities in repository-controlled configuration files. If an internal
development version is intentionally being used, document confirmation that the
patch disabling environment variable expansion in repository-controlled sources
is included.
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
BENCHMARK_REPORT.json{
"results": [
{
"command": "pacquet@HEAD",
"mean": 3.7593475716,
"stddev": 0.11726037632494568,
"median": 3.7397372743,
"user": 3.6582166999999997,
"system": 3.3053844800000007,
"min": 3.6214874743,
"max": 3.9569491433,
"times": [
3.8544025523000003,
3.6214874743,
3.9569491433,
3.6715700353,
3.7197398143,
3.8431796373,
3.6607095443,
3.7597347343,
3.6292649243,
3.8764378563
]
},
{
"command": "pacquet@main",
"mean": 3.7875540759,
"stddev": 0.15956822537415796,
"median": 3.7374209502999998,
"user": 3.6754098999999996,
"system": 3.2837043799999996,
"min": 3.6237493833,
"max": 4.0915631133,
"times": [
3.7672750843,
3.6237493833,
3.8202255683,
3.6530165273,
4.0498992383,
3.7439486063,
3.6884316163,
3.7065383273,
4.0915631133,
3.7308932943
]
},
{
"command": "pnpr@HEAD",
"mean": 2.2042905507,
"stddev": 0.0968405362187699,
"median": 2.2131557668,
"user": 2.7315512999999996,
"system": 2.87142938,
"min": 2.0788739113,
"max": 2.3388365863,
"times": [
2.0788739113,
2.2840279142999997,
2.1800069783,
2.0959904733,
2.1243501873,
2.2975987503,
2.2463045553,
2.1119592422999998,
2.3388365863,
2.2849569083
]
},
{
"command": "pnpr@main",
"mean": 2.0880754331999993,
"stddev": 0.11553643620824547,
"median": 2.0376526578,
"user": 2.7238416,
"system": 2.8943198800000003,
"min": 1.9705276923000001,
"max": 2.2606978223,
"times": [
2.2461408813,
1.9948779783,
1.9705276923000001,
2.0693150543,
2.0059902613,
2.2606978223,
2.2234855963,
2.0040793993,
1.9900324383,
2.1156072083
]
}
]
}Scenario: Isolated linker: fresh restore, hot cache + hot store
BENCHMARK_REPORT.json{
"results": [
{
"command": "pacquet@HEAD",
"mean": 0.6347979607400001,
"stddev": 0.012274161011000704,
"median": 0.6311594380400001,
"user": 0.38092812,
"system": 1.30328226,
"min": 0.62318781704,
"max": 0.6627326650400001,
"times": [
0.62318781704,
0.62462167104,
0.62755040604,
0.63441605704,
0.6333257910400001,
0.62982506204,
0.6627326650400001,
0.63109913204,
0.6500012620400001,
0.63121974404
]
},
{
"command": "pacquet@main",
"mean": 0.63083827394,
"stddev": 0.011156674294338895,
"median": 0.63175692104,
"user": 0.37629332000000004,
"system": 1.30627596,
"min": 0.6109701040400001,
"max": 0.6466285620400001,
"times": [
0.63294377404,
0.61710604104,
0.63057006804,
0.6109701040400001,
0.63997231004,
0.6466285620400001,
0.63471560904,
0.62779885104,
0.62496802504,
0.64270939504
]
},
{
"command": "pnpr@HEAD",
"mean": 0.67265496864,
"stddev": 0.018427286742073626,
"median": 0.6714367295400001,
"user": 0.38759392000000004,
"system": 1.3305381600000001,
"min": 0.64756998404,
"max": 0.71223911904,
"times": [
0.71223911904,
0.6777066230400001,
0.6710660310400001,
0.6868030930400001,
0.66000491204,
0.6532158210400001,
0.6798780670400001,
0.64756998404,
0.66625860804,
0.67180742804
]
},
{
"command": "pnpr@main",
"mean": 0.69419612714,
"stddev": 0.024116383082051898,
"median": 0.69061661904,
"user": 0.39423022,
"system": 1.33453266,
"min": 0.6618345870400001,
"max": 0.7379408190400001,
"times": [
0.7379408190400001,
0.68350283004,
0.68527958404,
0.71763487104,
0.69541296304,
0.6858202750400001,
0.71399789304,
0.69868903104,
0.66184841804,
0.6618345870400001
]
}
]
}Scenario: Isolated linker: fresh install, cold cache + cold store
BENCHMARK_REPORT.json{
"results": [
{
"command": "pacquet@HEAD",
"mean": 4.1786024800199995,
"stddev": 0.049803962609872805,
"median": 4.1740165314199995,
"user": 3.772125139999999,
"system": 3.2820125000000004,
"min": 4.12070578092,
"max": 4.28692559992,
"times": [
4.147711299919999,
4.15069414992,
4.20065705592,
4.196227275919999,
4.1884016079199995,
4.12277525892,
4.21229531592,
4.12070578092,
4.1596314549199995,
4.28692559992
]
},
{
"command": "pacquet@main",
"mean": 4.20923197002,
"stddev": 0.06915727371670327,
"median": 4.19376192942,
"user": 3.7937659399999992,
"system": 3.2901424999999995,
"min": 4.113464060919999,
"max": 4.31199052492,
"times": [
4.31199052492,
4.2526592039199995,
4.113464060919999,
4.28756391692,
4.156325273919999,
4.16002171292,
4.14224898892,
4.19033395592,
4.19718990292,
4.280522158919999
]
},
{
"command": "pnpr@HEAD",
"mean": 2.2088848107200003,
"stddev": 0.15214867406021407,
"median": 2.16208700442,
"user": 2.57012114,
"system": 2.8234501,
"min": 2.04009635092,
"max": 2.50395387292,
"times": [
2.04009635092,
2.13355023792,
2.06805645992,
2.3631394129200003,
2.29161922592,
2.1906237709200003,
2.50395387292,
2.0835852789200002,
2.10562144892,
2.30860204792
]
},
{
"command": "pnpr@main",
"mean": 2.13995772882,
"stddev": 0.11606151221854087,
"median": 2.10101814692,
"user": 2.5742454399999994,
"system": 2.8246705000000003,
"min": 2.02736351492,
"max": 2.3978749229200003,
"times": [
2.1113919559200003,
2.07906003792,
2.29231662492,
2.09991681092,
2.3978749229200003,
2.0697915939200002,
2.02736351492,
2.06229347792,
2.10211948292,
2.15744886592
]
}
]
}Scenario: Isolated linker: fresh install, hot cache + hot store
BENCHMARK_REPORT.json{
"results": [
{
"command": "pacquet@HEAD",
"mean": 1.3383753552,
"stddev": 0.020722498473697164,
"median": 1.3395973069,
"user": 1.3303943599999999,
"system": 1.68567048,
"min": 1.3130083834000001,
"max": 1.3767215524,
"times": [
1.3135010524000001,
1.3219231224,
1.3238085204,
1.3563310894,
1.3528059584,
1.3446121484,
1.3767215524,
1.3464592594,
1.3345824654,
1.3130083834000001
]
},
{
"command": "pacquet@main",
"mean": 1.3777769487,
"stddev": 0.07889596008540731,
"median": 1.3543643699,
"user": 1.3011509599999997,
"system": 1.7485325799999998,
"min": 1.3357089624,
"max": 1.5998488384000003,
"times": [
1.3482001154,
1.5998488384000003,
1.3535716474000001,
1.3551570924,
1.3561334984000002,
1.3445583074,
1.3357089624,
1.3440221264,
1.3619301324000002,
1.3786387664000002
]
},
{
"command": "pnpr@HEAD",
"mean": 0.6688595746000001,
"stddev": 0.021179658280857896,
"median": 0.6698242379,
"user": 0.34235496,
"system": 1.26912548,
"min": 0.6437483864,
"max": 0.7174498444,
"times": [
0.6689221414000001,
0.6437483864,
0.6587585794,
0.6726723464,
0.7174498444,
0.6824221084000001,
0.6739735694,
0.6507254674,
0.6707263344,
0.6491969684
]
},
{
"command": "pnpr@main",
"mean": 0.6564814813,
"stddev": 0.00820476243030796,
"median": 0.6571606193999999,
"user": 0.33541385999999995,
"system": 1.25918588,
"min": 0.6417268294,
"max": 0.6656002964,
"times": [
0.6561146184,
0.6417268294,
0.6531244534,
0.6647264264,
0.6656002964,
0.6449176304,
0.6611272424,
0.6645062644,
0.6582066204,
0.6547644314
]
}
]
}Scenario: Isolated linker: fresh install, cold cache + hot store
BENCHMARK_REPORT.json{
"results": [
{
"command": "pacquet@HEAD",
"mean": 3.1094409042200004,
"stddev": 0.039477470346176435,
"median": 3.11811951242,
"user": 1.8380058599999998,
"system": 1.9919653999999998,
"min": 3.04639659192,
"max": 3.16259045292,
"times": [
3.06554043992,
3.12795776292,
3.06303304792,
3.1038485099199997,
3.15372488192,
3.11928195892,
3.04639659192,
3.13507832992,
3.16259045292,
3.11695706592
]
},
{
"command": "pacquet@main",
"mean": 3.11333235652,
"stddev": 0.046735576990396904,
"median": 3.1063171274199997,
"user": 1.82974826,
"system": 2.0032189999999996,
"min": 3.05403101492,
"max": 3.20744205592,
"times": [
3.08396423492,
3.12672197892,
3.16146460392,
3.09516867292,
3.1344593659199997,
3.11746558192,
3.06233046292,
3.20744205592,
3.05403101492,
3.09027559292
]
},
{
"command": "pnpr@HEAD",
"mean": 0.6547622267200001,
"stddev": 0.018366240249240783,
"median": 0.6474695689200001,
"user": 0.34566446,
"system": 1.2550278,
"min": 0.62781307492,
"max": 0.69111274192,
"times": [
0.69111274192,
0.6466295229200001,
0.64570338392,
0.6592917179200001,
0.64830961492,
0.62781307492,
0.66432991492,
0.64564842692,
0.6761314969200001,
0.64265237192
]
},
{
"command": "pnpr@main",
"mean": 0.6524248119200001,
"stddev": 0.010496612469024625,
"median": 0.65595147992,
"user": 0.33715665999999994,
"system": 1.2581817999999996,
"min": 0.6330040279200001,
"max": 0.6638360749200001,
"times": [
0.65404035092,
0.6638360749200001,
0.6330040279200001,
0.6563483939200001,
0.6388039109200001,
0.65575497792,
0.65614798192,
0.6595988219200001,
0.6432935619200001,
0.6634200169200001
]
}
]
} |
|
Bencher Report| Branch | pr/12421 |
| Testbed | pacquet |
Click to view all benchmark results
| Benchmark | Latency | Benchmark Result milliseconds (ms) (Result Δ%) | Upper Boundary milliseconds (ms) (Limit %) |
|---|---|---|---|
| isolated-linker.fresh-install.cold-cache.cold-store | 📈 view plot 🚷 view threshold | 4,178.60 ms(+2.81%)Baseline: 4,064.45 ms | 4,877.34 ms (85.67%) |
| isolated-linker.fresh-install.cold-cache.hot-store | 📈 view plot 🚷 view threshold | 3,109.44 ms(+8.31%)Baseline: 2,870.85 ms | 3,445.02 ms (90.26%) |
| isolated-linker.fresh-install.hot-cache.hot-store | 📈 view plot 🚷 view threshold | 1,338.38 ms(+7.45%)Baseline: 1,245.62 ms | 1,494.74 ms (89.54%) |
| isolated-linker.fresh-restore.cold-cache.cold-store | 📈 view plot 🚷 view threshold | 3,759.35 ms(-4.81%)Baseline: 3,949.21 ms | 4,739.05 ms (79.33%) |
| isolated-linker.fresh-restore.hot-cache.hot-store | 📈 view plot 🚷 view threshold | 634.80 ms(+1.70%)Baseline: 624.22 ms | 749.06 ms (84.75%) |
|
| Branch | pr/12421 |
| Testbed | pnpr |
⚠️ 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-thresholdsflag.
Click to view all benchmark results
| Benchmark | Latency | milliseconds (ms) |
|---|---|---|
| isolated-linker.fresh-install.cold-cache.cold-store | 📈 view plot | 2,208.88 ms |
| isolated-linker.fresh-install.cold-cache.hot-store | 📈 view plot | 654.76 ms |
| isolated-linker.fresh-install.hot-cache.hot-store | 📈 view plot | 668.86 ms |
| isolated-linker.fresh-restore.cold-cache.cold-store | 📈 view plot | 2,204.29 ms |
| isolated-linker.fresh-restore.hot-cache.hot-store | 📈 view plot | 672.65 ms |
|
Code review by qodo was updated up to the latest commit 7742b7f |
This automated PR refreshes the project's pinned versions:
packageManageranddevEngines.packageManager).@pnpm/pacquetconfig dependency to its latest release.Created by the update-lockfile workflow.
Summary by CodeRabbit
This release includes maintenance updates to development tooling and dependencies.
@pnpm/pacquetto 0.11.7