Adds a note clarifying how to add new package managers #408
Conversation
Co-authored-by: Antoine du Hamel <[email protected]>
Co-authored-by: Antoine du Hamel <[email protected]>
| Once added, the shims pertaining to new package managers won't be automatically | ||
| enabled by `corepack enable` when called without arguments - it'll require users | ||
| to explicitly install the relevant shims (e.g. `corepack enable mypm`). A | ||
| separate PR adding the package manager to the default list can be opened a |
There was a problem hiding this comment.
It feels odd that a package manager would be enabled by default in corepack but not shipped enabled by default in node.js, it feels like these two things should be in lock step
There was a problem hiding this comment.
I agree with Myles. I think the primary way in which users will interact with Corepack will be with the default Node.js install. So I'm curious why we would want Corepack to behave differently when installed another way?
There was a problem hiding this comment.
I believe the idea was to make corepack enable without arguments relatively liberal (since it requires an explicit action from the user), vs Node.js inclusion which would require some extra vetting since it has implications on what gets added to the standard distribution (for instance, would Node.js want to ship a bun binary? #295).
In a sense, that's already the current situation: Node.js doesn't ship the Yarn / pnpm binaries by default, despite corepack enable installing them both.
| Finally, this repository does not manage which package managers are distributed | ||
| with default install of Node.js. This is managed in the | ||
| [nodejs/node](https://github.com/nodejs/node) repository, refer to the | ||
| [CONTRIBUTING.md](https://github.com/nodejs/node/blob/main/CONTRIBUTING.md) over |
There was a problem hiding this comment.
Is there existing documentation / governance?
There was a problem hiding this comment.
PR reviewing process is documented in nodejs/node yes, but I feel like that's not what you're asking. I suggested this phrasing so this doesn't become outdated when/if such process changes on the nodejs/node side.
|
@arcanis I think that PRs like this that involve governance (also design decisions and the like) need much more review than being opened and merged in a matter of hours. The TSC should be tagged, as well as relevant teams like Alternatively we could define Corepack’s governance and design in the core repo. |
We didn't document the process to add new package managers to Corepack. I added a rough draft based on the discussions we had around the topic lately, feel free to suggest improvements in wording or content.