Uh oh!
There was an error while loading. Please reload this page.
feat: add support for .corepack.env - #642
Conversation
styfle
commented
Feb 9, 2025
I'm not sure about this feature. Adding a config file sounds like increased complexity for very little benefit. Do you have examples of when you might use this? |
aduh95
commented
Feb 9, 2025
The tests in this PR as well as in #634 are good examples I think |
aduh95
commented
Feb 10, 2025
And #628 of course |
| Only keys that starts with `COREPACK_` will be taken into account, not all | ||
| keys that start with `COREPACK_` will be taken into account ( | ||
| `COREPACK_ENABLE_DOWNLOAD_PROMPT` and `COREPACK_ENV_FILE` are ignored). |
There was a problem hiding this comment.
This would be worth a test, especially for COREPACK_ENABLE_DOWNLOAD_PROMPT (assuming you omitted it for security reasons?)
There was a problem hiding this comment.
Good call (yes, btw I’m happy to add more which we think could be security sensitive)
Uh oh!
There was an error while loading. Please reload this page.
Co-authored-by: Mike McCready <66998419+MikeMcC399@users.noreply.github.com>
Uh oh!
There was an error while loading. Please reload this page.
This would allow project author to customize the behavior of Corepack – with the recent incident related to npm registry key rotation, it show how it would be useful to override the built-in values. It could also be used to disable auto pinning at a project level.
It's also a first step towards allowing specifying ranges in the
package.json(see #634), which has been requested for a long long time (#95).Fixes: #628