oxc-project
oxc-resolver
Blog
Docs
Changelog
Blog
Docs
Changelog
Overview
Branches
Benchmarks
Runs
Performance History
Latest Results
test: verify node_modules canonicalization across layouts Add `node_modules_canonicalize.rs` and committed symlink fixtures asserting the resolver's canonicalization equals `std::fs::canonicalize`: - `canonicalize_matches_os_for_all_node_modules` walks every path in each installed `fixtures/bench-pm/installs/<combo>/node_modules` tree (skipped when the fixtures are not installed). - `symlinked_package_anchor_walks_suffix_symlinks` — a symlinked workspace anchor with a suffix symlink below it. - `real_package_anchor_walks_internal_symlinks` — a real anchor that ships an internal directory/file symlink. - `nested_monorepo_canonicalize_matches_os` — a monorepo version conflict where a workspace nests its own dependency version via an isolated-store symlink. These pass on main; they pin canonicalization correctness independent of any resolver optimization.
node-modules-canonicalize-tests
2 hours ago
test: add nested-monorepo canonicalization fixture A monorepo version conflict — root resolves `dep@2`, a workspace package nests its own `dep@1` via an isolated-store symlink. The test walks the fixture (incl. through symlinked directories) asserting the resolver's canonicalization equals `std::fs::canonicalize`, and checks each package's anchor resolves to its own store version.
perf/node-modules-anchor-fast-paths
2 hours ago
test(bench-pm): add monorepo node_modules layouts (nested + cross-workspace) The workspace packages had no dependencies, so every request resolved against the single root `node_modules` and the monorepo dimension was unexercised. Give them dependencies that create per-workspace `node_modules`: - `packages/ui` depends on `react@17.0.2` while the app uses `react@18.3.1`, so the conflict un-hoists a nested `packages/ui/node_modules/react` (flat) or `packages/ui/node_modules/react -> .pnpm/react@17.0.2/...` (isolated). - `packages/utils` depends on `@bench/ui` (`workspace:*`) — a workspace-to- workspace link; npm uses `*` via a config override. Two new `package_managers` workload requests resolve `react` from `packages/ui` (the nested 17) and `@bench/ui` from `packages/utils`. Lockfiles regenerated for all combos; `node_modules_canonicalize` now walks ~12.4k paths across the combos and still matches `std::fs::canonicalize`.
perf/node-modules-anchor-fast-paths
3 hours ago
perf(cache): node_modules-anchor fast paths Two fast paths for resolving inside `node_modules`, sharing one allocation-free `Cache::pkg_anchor` (a parent-chain walk with no syscalls) to the deepest `<...>/node_modules/<pkg>` directory (the "anchor"). 1. Canonicalize the anchor, not every component. `canonicalize_with_visited` canonicalizes the real anchor — recursively, so a symlinked project root (`/tmp`->`/private/tmp`, a Windows junction) is still resolved — and appends the suffix below it without a per-component `read_link` walk. A symlinked anchor (a linked workspace package, or the top-level link of an isolated layout) takes the normal walk instead. The suffix is appended only after `suffix_below_anchor_is_symlink_free` confirms every component strictly below the anchor is a real, non-symlink entry — reusing the cached `lstat`, so it is free for components already stat'd while resolving the file. An internal package symlink (`lib -> dist`, a re-export file) or a `..` suffix falls back to the normal walk. Correct for any layout because it verifies the suffix rather than assuming it from a detected layout. 2. Jump to the package's `package.json`. `find_package_json_for_a_package` jumps straight to the anchor's `package.json` instead of probing every intermediate directory, falling back to the directory walk when dependency tracking is enabled (so `missing_dependencies` stays byte-identical for watch consumers) or when the anchor has no manifest of its own. Syscalls on the 16-request `package_managers` workload vs `main`: | combo | main | now | |------------------------------|------|-----| | npm / yarn / bun-flat | 96 | 75 | | pnpm-isolated / pnpm-hoisted | 121 | 100 | | yarn-isolated | 114 | 93 | | bun-isolated | 121 | 100 | | yarn-pnp | 164 | 120 | Tests: `node_modules_canonicalize.rs` asserts the resolver's canonicalization equals `std::fs::canonicalize` for every path in every installed package-manager fixture; committed symlink fixtures cover a real anchor with internal dir/file symlinks and a symlinked workspace anchor with a suffix symlink.
perf/node-modules-anchor-fast-paths
5 hours ago
refactor(cache): drop node_modules layout detection; the suffix check suffices The anchor fast paths were gated on a detected `node_modules` layout (`NodeModulesLayout` / `trusts_node_modules_anchor`), but that gate was both unnecessary and a net cost. It was unnecessary because correctness comes from elsewhere: - The canonicalize fast path canonicalizes a real `<...>/node_modules/<pkg>` anchor and appends the suffix only after `suffix_below_anchor_is_symlink_free` confirms every component below the anchor is a real (non-symlink) entry — reusing the cached `lstat`, so components already stat'd while resolving the file cost nothing. A symlinked anchor or a symlink in the suffix falls back to the normal per-component walk. So it is already correct for any layout. - The package.json jump already falls back to the directory walk when the anchor has no manifest, so the layout gate guarded nothing there. It was a net cost because detection ran a `metadata` ancestor-walk per `node_modules` tree — once per nested store directory for isolated/pnp layouts, which regressed them (yarn-pnp 164 -> 221). Removing it makes every layout faster than `main` on the 16-request package-managers workload: | combo | main | now | |---|---|---| | npm / yarn / bun-flat | 96 | 75 | | pnpm-isolated / pnpm-hoisted | 121 | 100 | | yarn-isolated | 114 | 93 | | bun-isolated | 121 | 100 | | yarn-pnp | 164 | 120 |
perf/node-modules-anchor-fast-paths
7 hours ago
fix(cache): follow symlinks below node_modules anchors; detect layout per tree The anchor fast path appended the suffix below a real `<...>/node_modules/<pkg>` directory without following symlinks. That is wrong when a package ships an internal symlink below its real anchor — a directory link (`lib -> dist`) or a re-export file link — because the canonical path then skips the link. Verify that every component strictly below the anchor is a real entry (reusing the cached lstat, so components already stat'd while resolving cost nothing) before appending; otherwise take the normal per-component walk. Symlinked anchors (workspace links, isolated store links) keep the walk too. Classify the `node_modules/` layout per tree, keyed by the nearest enclosing `node_modules` directory so detection runs once per tree instead of on every canonicalize. A nested `node_modules` (a package's own dependency tree) is classified independently. Recognized layouts need a virtual store (`.pnpm`/`.store`/`.bun`), a `.pnp.cjs`, or a lockfile marker. Fixtures and tests cover a real anchor with internal dir/file symlinks and a symlinked workspace anchor with a suffix symlink.
perf/node-modules-anchor-fast-paths
10 hours ago
fix(cache): gate the node_modules anchor fast paths on a detected layout The anchor fast paths assume nothing is a symlink strictly below a `<...>/node_modules/<pkg>` directory. That holds for package-manager installs but not for an arbitrary hand-built or custom-FileSystem `node_modules/`, where the per-component canonicalize walk could need to follow a symlink the fast path skips. Classify the `node_modules/` layout once (cached on the Cache) by probing for markers — `.pnp.cjs` (Pnp), a `.pnpm`/`.store`/`.bun` virtual store (Isolated), or a bare `node_modules/` (Flat) — and only take the anchor fast paths for a recognized layout. An unrecognized tree (Generic) falls back to the normal per-component walk. Internal only, no ResolveOptions surface. All recognized package-manager layouts stay on the fast path, so the syscall win is preserved for real installs.
perf/node-modules-anchor-fast-paths
24 hours ago
fix(cache): gate the node_modules anchor fast paths on a detected layout The anchor fast paths assume nothing is a symlink strictly below a `<...>/node_modules/<pkg>` directory. That holds for package-manager installs but not for an arbitrary hand-built or custom-FileSystem `node_modules/`, where the per-component canonicalize walk could need to follow a symlink the fast path skips. Classify the `node_modules/` layout once (cached on the Cache) by probing for markers — `.pnp.cjs` (Pnp), a `.pnpm`/`.store`/`.bun` virtual store (Isolated), or a bare `node_modules/` (Flat) — and only take the anchor fast paths for a recognized layout. An unrecognized tree (Generic) falls back to the normal per-component walk. Internal only, no ResolveOptions surface. All recognized package-manager layouts stay on the fast path, so the syscall win is preserved for real installs.
perf/node-modules-anchor-fast-paths
1 day ago
Latest Branches
CodSpeed Performance Gauge
+4%
test: verify node_modules canonicalization across layouts
#1200
2 hours ago
dbfbbab
node-modules-canonicalize-tests
CodSpeed Performance Gauge
-4%
perf: node_modules-anchor fast paths
#1189
2 hours ago
49b94fa
perf/node-modules-anchor-fast-paths
CodSpeed Performance Gauge
+4%
chore: release v11.21.0
#1178
1 day ago
7a75c9e
release-plz-2026-05-28T15-25-06Z
© 2026 CodSpeed Technology
Home
Terms
Privacy
Docs