feat(internal/librarian/nodejs): use pnpm install

[quirogas]

TLDR

This PR refactors our Node.js installer inside librarian. We migrated from our current practice of using the npm CLI wrapper to the pnpm toolchain utilizing corepack to establish absolute package linkage determinism.

By using pnpm and adhering to the lock files installation, we can create a deterministic installation environment. Matching our tool versions to those specified in the lockfiles allows us to match our current generation pipeline output.

---

Context: Why should we transition to pnpm instead of npm?

1. Deterministic Dependency Isolation: Standard npm installations are deterministic when consuming local project files under package-lock.json. However, our current practice of performing dynamic global package installations inside librarian (e.g., executing npm install -g gapic-tools@1.0.5 on host environments) does not respect lockfiles, floating transitives dynamically. Standardizing on pnpm resolves this by strictly respecting pnpm-lock.yaml across our source-built target tools.
2. Infrastructure Alignment: Moving to pnpm directly reflects and aligns our local generation tools with the hermetic sandboxing configurations we use upstream in our current bazel-bot pipeline and postprocessor.
3. Monorepo Support & Forward Outlook: The Node.js platform team has expressed a strategic intent to migrate libraries and generators entirely to pnpm in the future due to its first-class workspace support and content-addressable storage design tailored for monorepos.
4. Complete npm Decoupling: To eliminate the runtime footprint of the npm binary during tool bootstrapping, we successfully transitioned our installer to Node.js's built-in corepack wrapper.
   • Our installer now automatically creates and maps standard executable bin shims globally using corepack enable pnpm first.
   • Our installer activates the target version globally via corepack prepare pnpm@7.32.2 --activate.
   • Our installer queries Node's native process.execPath folder path directly in JavaScript (node -e "console.log(require('path').dirname(process.execPath))") to configure pnpm's global-bin-dir. This runs completely independently of standard npm config calls.
5. Clean Global Links: We replaced npm link with pnpm link --global to bind the compiled typescript generator to our shared global virtual store.

---

Why do should we explicitly specify protobufjs?

During local runs of the generator we created against google-cloud-secretmanager, the generated protos.js file introduced a substantial diff containing recursive depth limits (long > $util.recursionLimit) and prototype pollution validations (keys[i] !== "__proto__").

We traced this discrepancy back to a peer dependency resolution mismatch:

• The Mismatch: Upstream compiler shims rely on protobufjs-cli, which depends on protobufjs as a peer dependency. In floated global registry environments, this peer dependency resolves to the latest protobufjs@7.6.0, which automatically injects these recursion and security checks into the generated JavaScript AST.
• Does pnpm not address this?:
  • Normally, when executing project-level installations inside folders with locked files (pnpm install), pnpm's virtual store correctly isolates peer dependencies according to the locks.
  • However, because gapic-tools (which contains the compileProtos compilation shim) is installed from the NPM registry globally (pnpm add -g), published packages do not bundle a lockfile.
  • In the absence of a lockfile, pnpm dynamically resolves the floated peer range ^7.5.3 under protobufjs-cli to the latest minor version (7.6.0), triggering the security and depth limit checks.
• The Current Pipeline: However, our current bazel-bot pipeline runfiles are hermetically isolated. During historical compilation, the peer dependency resolved to the only available, older protobufjs sub-dependency bundled inside the sandbox (specifically 7.5.4 / 7.5.5), generating AST files without these checks.
• The Aligned Solution:
  • To resolve this peer range drift and align with our pipeline output, we added direct peer pins for protobufjs-cli@1.2.0 and protobufjs@7.5.5 inside our tools configuration block in librarian.yaml.
  • This forces the global pnpm virtual store to link the peer dependencies directly to the correct pre-patched versions, resolving the version-mismatch checks completely (leaving only benign monorepo root namespace registry adjustments!).

[gemini-code-assist]

Code Review

This pull request migrates the Node.js tool installation logic from npm to pnpm, updating the configuration schema, internal structs, and installation procedures. The changes include activating pnpm via corepack and dynamically setting the global binary directory. Feedback suggests defining the hardcoded pnpm version as a constant and using environment variables instead of persistent global configuration commands to avoid side effects on the host environment.

[coryan]

Those extra return statements after t.Fatal() and after t.Fatalf() seems wrong, please revert.

[JoeWang1127]

Could you revert the changes in sidekick directory? They seems redundant.

[JoeWang1127]

Could you fix the unit tests?

No longer affects Rust.