feat: let .corepack.env be a lock file

[aduh95]

With #642 and #643 landed, we can consider using .corepack.env as a lockfile. If the package.json defines a devEngines.packageManager, we can accept an env variable that defines the exact version Corepack should be using; if that version is put in a .corepack.env (Node.js 20+ users only), it's effectively a lockfile.

I'm not a fan of the env variable name chosen, happy to use a different one.

Fixes: #402
Fixes: #95
Fixes: #682

[styfle]

To be clear, this is only going to update .corepack.env if it already exists.

Its not going to create .corepack.env if it does not exist, right?

[aduh95]

To be clear, this is only going to update .corepack.env if it already exists.

Its not going to create .corepack.env if it does not exist, right?

Yes correct, if it exists and contains the env key – so it’s currently opt-in, I think we could discuss whether we want to flip that to opt-out once the parseEnv thing is no longer experimental.

[arcanis]

Why do we need that considering that packageManager can already be used as a lock for devEngines.packageManager?

[aduh95]

Why do we need that considering that packageManager can already be used as a lock for devEngines.packageManager?

So one can git ignore it I believe is the ask

[arcanis]

I'm not sure I follow the use case. Why would they use Corepack (or devEngine) if they don't want to lock the version in the project?

[zanminkian]

@arcanis I have the same use-case as @aduh95. When developing some old projects, they usually reject to add packageManager and devEngines field to package.json. Corepack is convenient for me but not every team member like it. I can use corepack with a git ignored .corepack.env file on my own way.

[arcanis]

Then disable auto pinning? I don't think this behavior should have been made the default anyway.

[aduh95]

@zanminkian could you give an example of use case where putting a .gitignored .corepack.env with COREPACK_ENABLE_AUTO_PIN=0 would not fulfill your needs?

[styfle]

Then disable auto pinning? I don't think this behavior should have been made the default anyway.

I tend to agree. I believe the default auto-pinning was added as a response to earlier TSC meetings where this was a recommendation to making corepack stable and default enabled with node distributions.

Now that corepack is no longer going to be bundled with node, we could consider disabling the auto pinning behavior.