Auto-activate package.json packageManager via Corepack in nodejs plugin#2845
Merged
Conversation
When Corepack is enabled, the nodejs plugin now reads the `packageManager` field from the project's package.json and runs `corepack prepare --activate` so the pinned package manager (pnpm, yarn, or npm) is available in the shell. This is generalized to any package manager and enabled by default. Set DEVBOX_DISABLE_NODEJS_PACKAGE_MANAGER_AUTODETECT=1 to disable it. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Pull request overview
This PR extends the built-in nodejs plugin so that, when Corepack is enabled, Devbox automatically reads the project’s package.json#packageManager field and runs corepack prepare --activate to make the pinned package manager available in the shell (with an opt-out via DEVBOX_DISABLE_NODEJS_PACKAGE_MANAGER_AUTODETECT=1).
Changes:
- Update the nodejs plugin README text to document automatic package manager activation and the disable flag.
- Add an
init_hookstep that detectspackageManagerfrompackage.jsonand activates it via Corepack when enabled.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Assert the Corepack-activated pnpm version matches the pinned packageManager field, exercising the nodejs plugin autodetect. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Quote the DEVBOX_COREPACK_ENABLED guards so they behave reliably when the var is unset, and build the package.json path from process.env.DEVBOX_PROJECT_ROOT inside Node instead of interpolating the shell variable into the JS source (which could break on paths containing quotes or backslashes). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
mohsenari
approved these changes
Jun 4, 2026
Cover the two no-op cases for the nodejs plugin's autodetect init_hook: package.json missing, and package.json present without a packageManager field. Both must leave shell init working without error. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Replace the inline shell + node -e one-liner with a dedicated activate-package-manager.js shipped via create_files and invoked from the init_hook. This is easier to read and maintain than the escaped one-liner. The corepack enable / PATH export lines stay in shell since exporting PATH must mutate the parent shell environment. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Collapse the three init_hook shell commands into a single `eval "$(node setup-corepack.js <corepack-bin-dir>)"`. The script now enables Corepack, activates the pinned packageManager, and prints the `export PATH=...` line for the shell to eval (a child process can't mutate the parent shell's PATH, so the export is emitted and eval'd). Renamed activate-package-manager.js -> setup-corepack.js to reflect its broader responsibility. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The script now early-exits unless DEVBOX_COREPACK_ENABLED is set, so the init_hook no longer needs the shell-side guard and is a single eval "$(node setup-corepack.js <corepack-bin-dir>)". When disabled the script emits nothing, so the eval is a no-op. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Declare the corepack-bin dir in the plugin's env block (and add it to PATH, matching the ruby plugin's pattern), so setup-corepack.js no longer needs to emit an export for the shell to eval. The init_hook is now simply `node <virtenv>/bin/setup-corepack.js`, and the script reads the bin dir from DEVBOX_COREPACK_BIN_DIR. Bumped plugin version to regenerate the shipped script. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Bump nodejs plugin_version to 0.0.3 in the example lockfiles. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
When Corepack is enabled (
DEVBOX_COREPACK_ENABLED=1), the nodejs plugin now reads thepackageManagerfield from the project'spackage.jsonand runscorepack prepare --activateso the pinned package manager (pnpm, yarn, or npm) is ready in the shell. The behavior is generalized to any package manager and enabled by default; setDEVBOX_DISABLE_NODEJS_PACKAGE_MANAGER_AUTODETECT=1to disable it.How was it tested?
Validated that
plugins/nodejs.jsonstill parses as valid JSON and that the newinit_hookentry renders the expected shell. The hook is guarded so it only runs when Corepack is enabled, the disable flag is unset, and apackage.jsonexists, and it emits nothing when nopackageManagerfield is present.Community Contribution License
All community contributions in this pull request are licensed to the project
maintainers under the terms of the
Apache 2 License.
By creating this pull request, I represent that I have the right to license the
contributions to the project maintainers under the Apache 2 License as stated in
the
Community Contribution License.