build: stop distributing Corepack

[aduh95]

Refs: nodejs/TSC#1697 (comment)

[ljharb]

Is there a reason to keep the ability to build node with corepack? that doesn't seem in line with the TSC decision.

[ljharb]

Suggested change

	help='do install the bundled Corepack')
	help='bundle Corepack')

[aduh95]

Suggested change

	help='do install the bundled Corepack')
	help='do install the bundled Corepack (experimental, will be removed without notice)')

[ljharb]

"do install" at the front of the sentence doesn't read like proper english to me, and there is no "bundled corepack" anymore to install - this flag causes it to be bundled.

[aduh95]

I agree that "bundled Corepack" is weird, maybe "vendored" would be more appropriate?

[ljharb]

the problem is the "the" - there is no "bundled corepack" anymore. the flag causes corepack to BE bundled, and "bundle" is a verb, which is why "bundle corepack" seems like the best/proper phrasing to me (with or without the experimental note)

[aduh95]

that doesn't seem in line with the TSC decision.

What makes you think that?

Is there a reason to keep the ability to build node with corepack?

Yes, so we can keep it up-to-date across the release lines

[ljharb]

My read of the TSC decision is to not include corepack in any way whatsoever in 25+, not to make it optionally bundled and just change the default. iow, it's meant to be removed entirely.

Yes, so we can keep it up-to-date across the release lines

This commit will only be landing in v25+, though. Won't existing release lines lack this commit, and continue to build it with corepack by default?

[aduh95]

iow, it's meant to be removed entirely.

No, it was very explicit that the decision was about including (or not) a corepack executable in the distribution. Removing the vendored version from the repo would not be reasonable until 24.x is EOL. Anyway, does it matter?

Won't existing release lines lack this commit, and continue to build it with corepack by default?

That's correct, and in line with the TSC decision linked in the OP.

[ljharb]

Right - node < 25 should continue to bundle corepack unchanged. node 25+ shouldn't even offer the option to build it with corepack, because the TSC decision was to "not include the corepack executable" - not to "not include the corepack executable by default".

If the option to build node with corepack remains in 25+, more people may be encouraged to compile node themselves rather than using the official binaries, which would magnify support burden for the project, and proliferate variants of node which could cause compatibility concerns down the line.

[targos]

It's true that there's a risk to see unofficial distributions like the one from homebrew to keep including corepack. But this PR can be followed up by another one that removes it completely.

[ljharb]

That's true, it just seems like a silly unnecessary step :-)

[aduh95]

Commits need to land on main first, so there's no way we remove the vendor version for the time being, not without giving us a lot more work. If folks go as far as to compile node themself rather than downloading Corepack in any other possible way, I don't think we can do anything for them, they might also patch this repo to re-add Corepack you know.

[ljharb]

main won't ever touch < 25 though in its entirety - the vendored version can be removed from main and it shouldn't affect any of the other release lines - or is there some complex interaction that i'm missing?

[marco-ippolito]

I mean we could keep corepack in the deps folder but remove the ability to build it. This allows the automation to keep updating it and just cherry-pick commits into old release lines and at some point we remove it completely.
But it should not be possible to build node with corepack otherwise redistributors will enable it, so I think we should remove completely the ability to build.
Also isn't this semver major?

[aduh95]

otherwise redistributors will enable it

Should we care?

[marco-ippolito]

otherwise redistributors will enable it

Should we care?

I think we should

[ljharb]

I also already explained above why we should care.

[aduh95]

I'm not convinced. If we want folks to stop using Corepack, we should spend time on building an alternative, not spend time on making their life harder. Also I'm not even convinced it would be more effective: I'm a maintainer of Nixpkgs Node.js packages, and I can tell you it is as easy to pass a configure flag than it is to revert a specific commit for redistributors, so I'm afraid your concern is not addressable.
TL;DR, I'm not going to do it, it's not worth my time, let's please move on.

[marco-ippolito]

I'll ping @nodejs/tsc for visibility as I think it's worth being aligned on this decision

[RaisinTen]

Whether to remove the ability to build corepack is a separate decision. This change is already a step in the right direction and is aligned with the vote results, so LGTM.

[mhdawson]

Whether to remove the ability to build corepack is a separate decision. This change is already a step in the right direction and is aligned with the vote results, so LGTM.

[mhdawson]

LGTM

[ljharb]

It's fine to land this as an incremental step, but I don't think it's a separate decision - the ability to build node with corepack is part of what the TSC vote decided to remove.

[MikeMcC399]

• probably PR deps: remove corepack #51981 should be closed as it would be superseded by this PR I believe. It's locked so I can't comment there

[mcollina]

lgtm