Geoffrey Booth

> Just a first quick take on this, why `npm install corepack` and not `npm install yarn`? Because Yarn wishes to be installed via Corepack. `npm install yarn` installs Yarn...

If we remove `npm`, we just refactor this to download via `fetch`. Or it downloads via `fetch` in the first place. The implementation details are irrelevant. The point is, is...

> I was not around where and when corepack was being conceived or implemented, so I don’t 100% understand what problems its trying to solve. It was designed to solve...

> Because it creates a dependency on npm that wasn’t there before Whether Yarn or pnpm are downloaded via npm or via some other means is an irrelevant implementation detail....

I just did some experimenting in a `node` Docker container and I think this is achievable in 9 lines of code. We could have this file be saved into `/usr/local/bin/pnpm`:...

> Having a yarn binary in the PATH that doesn't actually behave like yarn That's what enabling Corepack does: it puts binaries in the path that are named `yarn` and...

This came up in https://github.com/nodejs/package-maintenance/issues/591 too, in that our webpage’s primary download link is for unmanaged Node, like an installer, yet our recommended way for installing Node is via a...

> You mean as a link to the actual Markdown doc? However you want to do it; a link, or pulling that document into the build for the website somehow,...

> while loaders _are_ experimental, ESM itself is specifically marked as _stable_ CommonJS is stable too but the monkey-patching that APM vendors do to make instrumentation work there is completely...

The loaders roadmap is here: https://github.com/nodejs/loaders. You can watch that repo for changes. That would give you many weeks or months heads-up before something lands. Whenever a PR gets opened...