Prefer using exclusively Corepack when possible

[arcanis]

What's the problem this PR addresses?

Node 14 will soon be the new Node LTS. Since it ships with Corepack, we don't need to store the version file unless users already expect really want it.

How did you fix it?

The new code detects whether there's a yarnPath setting. If there is, it assumes that the version file will be needed. Otherwise, it just updates the packageManager field.

Checklist

• I have read the Contributing Guide.

• I have set the packages that need to be released for my changes to be effective.

• I will check that all automated PR checks pass before the PR gets reviewed.

[merceyz]

If there is no yarnPath value already present, how would you force Yarn to set it?

[arcanis]

If there is no yarnPath value already present, how would you force Yarn to set it?

I've added a --yarn-path setting that will forcibly set yarnPath.

[merceyz]

Needs tests

[ylemkimon]

If Corepack is not enabled (which is by default), wouldn't this make Yarn classic (1.x) come into action? I think it should create a stub/placeholder binary to let people know Corepack is required for the time being, and ignore it in binary comparison.

[arcanis]

If Corepack is not enabled (which is by default), wouldn't this make Yarn classic (1.x) come into action?

The PR title isn't accurate at the moment; Yarn will prefer using exclusively Corepack when possible, but if it isn't enabled (COREPACK_ROOT isn't in the environment) it'll fallback on yarnPath.

[ylemkimon]

I was thinking of situations where a project created on an environment with Corepack enabled (hence no yarnPath) is shared with environments where Corepack is not enabled.

[arcanis]

Yes, in that situation it won't work in the current state. To address that I'm considering adding Corepack support to the Yarn 1.x distribution (but only for the yarn binary, of course), so that any of corepack enable / npm install -g yarn would be as if Corepack was installed.