Skip to content

Support lockfile generation and include lockfiles for NodeJSToolBase subsystems#23290

Open
riisi wants to merge 4 commits intopantsbuild:mainfrom
riisi:nodejs-tool-bundled-lockfiles
Open

Support lockfile generation and include lockfiles for NodeJSToolBase subsystems#23290
riisi wants to merge 4 commits intopantsbuild:mainfrom
riisi:nodejs-tool-bundled-lockfiles

Conversation

@riisi
Copy link
Copy Markdown
Contributor

@riisi riisi commented Apr 24, 2026

Fixes #23108

This PR was written primarily by Claude Code.
I've run a few auto review cycles with Claude and then been through and tweaked quite a bit to align with style etc.

Rhys Madigan added 4 commits April 24, 2026 11:29
Adds a bundled-lockfile execution path to NodeJSToolBase: with a
lockfile present, tools are installed via `npm ci` / `yarn --frozen-lockfile`
/ `pnpm install --lockfile-only` and then executed directly from
node_modules/.bin instead of `npx`/`dlx`, which avoids a per-invocation
download and pins transitive dependencies.

Prettier, Pyright, Spectral, openapi-format, and Redocly now declare
default_lockfile_resources and ship committed lockfiles for all three
package managers. TypeScript opts out via lockfile_required=False since
it always uses a project resolve.

NodeJS tools are wired into the generate-lockfiles goal via a new
GenerateNodeJSToolLockfile request, and build-support/bin/generate_builtin_lockfiles.py
gains --all-nodejs for bulk regeneration.
Follow-ups on the bundled-lockfile commit:

- Hoist shared helpers (package.json synthesis, lockfile-dest path, PM
  lookup, npm-spec parsing) into nodejs_tool.py so nodejs_tool.py,
  goals/lockfile.py, and build-support all call one source of truth
  instead of copy-pasting.
- Replace NodeJSToolBase's __init__ check with an __init_subclass__ hook
  that auto-derives default_lockfile_resources from the subsystem's own
  module + options_scope. Tool subsystems no longer declare the dict at
  all unless they need a non-conventional location; TypeScript still opts
  out via lockfile_required = False.
- Package the per-backend registration boilerplate as
  nodejs_tool.rules_for_tool(cls), replacing the manual
  UnionRule(ExportableTool, cls) line in each backend's rules().
- Fix install-failure handling: both the runtime install and the
  lockfile-generation rule now wrap execute_process in
  fallible_to_exec_result_or_raise so failures surface with stdout/stderr
  instead of silently producing an empty/partial digest.
- Use the canonical DEFAULT_TOOL_LOCKFILE from pants.core.goals.generate_lockfiles
  instead of shadowing it locally.
- Build-support script now uses PackageManager.{npm,yarn,pnpm}(None) for
  lockfile commands + filenames instead of hardcoding them, and runs each
  (tool, pm) pair in its own tmp dir.
- Add a regenerate-instructions header next to each backend's
  resources(name="lockfiles", ...) BUILD target.
Drive `generate_builtin_lockfiles.py --all-nodejs` through
`npx --yes <pm>@<version>` using the versions from
`[nodejs].package_managers`, so generated lockfiles don't depend on
whichever npm/yarn/pnpm happens to be on the developer's PATH. Yarn is
pinned to 1.x, which is what the NodeJS subsystem has been tested
against. Regenerated the openapi-format, redocly, and spectral
lockfiles to match.

Also drops two unused `UnionRule` imports added in the previous commit
and removes a redundant inline comment.
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.

include lockfiles for NodeJSToolBase subsystems

1 participant