v1.223.1-rc.0

🚀 Enhancements

fix(toolchain): repair dangling onedir symlink entrypoints (node) Brian Ojeda (@sgtoj) (#2754)

## what

• onedir (multi-file) installs now recreate an archive's internal symlink entrypoints using the archive's original relative target (e.g. ../lib/node_modules/corepack/dist/corepack.js) instead of a root-rebased path.
• Fixes nodejs/node, whose corepack/npm/npx entrypoints are symlinks into a sibling ../lib/ tree:
  • node@<=24.10.0 (whose files: list leads with corepack) no longer fails the install with chmod .../bin/corepack: no such file or directory.
  • node@24.18.0 no longer reports success while leaving npm/npx dangling.
  • After install, node, npm, npx, and corepack all resolve to real files and run.
• Adds a regression test that installs a leading-symlink onedir package under a relative install_path (the real-world default, e.g. install_path: .tools) and asserts the entrypoint resolves via os.Stat (follows the link) and is chmod-able — the exact operation that failed.
• Updates the symlink-target unit assertions to expect the archive-relative target, and corrects the onedir docs note that claimed targets are "recreated absolute."

why

• createValidatedSymlinkForOS wrote the containment-validated resolved path as the symlink target. resolved is the target rebased onto the toolchain root, so with a relative install root (the default .tools) it became a cwd-relative path. A symlink is interpreted relative to its own directory, so .../bin/corepack -> .tools/bin/.../lib/... resolved to .../bin/.tools/bin/.../lib/... and dangled. This reproduced independently of install_path.
• Writing the archive's original relative linkname reproduces the upstream archive exactly and resolves correctly whether the install root is absolute or relative.
• resolved is still used for the security containment check and the Windows copy/hard-link fallback, and absolute targets are still rejected — no change to the archive-symlink "arbitrary file write" protection.
• Note: this is a POSIX-only change (macOS/Linux). Windows onedir installs don't create symlinks — an archive's file symlink is reproduced as a hard link/copy via that unchanged resolved-based fallback, and nodejs/node ships .cmd shims there — so Windows behavior is unaffected.

references

• Follow-up to #2750 (multi-file / "onedir" installs), which shipped the onedir install path but left nodejs/node's internal symlink entrypoints dangling.
• Testing: go test ./pkg/toolchain/... ./cmd/toolchain/... passes; the new regression test fails on the pre-fix code with the exact chmod ... corepack: no such file or directory error. Also exercised on a GitHub-hosted windows-latest runner (pkg/toolchain/installer package green; symlink-privilege tests self-skip on Windows, Windows hard-link/copy fallback covered).

Summary by CodeRabbit

• Bug Fixes

  • Fixed onedir installations so archived relative symlinks resolve correctly when using absolute or relative install paths.
  • Ensured symlink-based entry points correctly resolve to their target executables.

• Documentation

  • Clarified that archived symlinks retain their relative targets while remaining safely within the installation package.