chore(yarn): Add package.json#packageManager field

[donmccurdy]

Once Yarn v2+ has been installed locally in a development environment, it comes with Corepack as the preferred way to install package managers. However, Volta (if installed) silently and globally disables Corepack...

• corepack enable exits successfully (exit code 0), but isn't actually enabled nodejs/corepack#507 (comment)
• volta install corepack doesn't provide corepack's yarn volta-cli/volta#987

... which has caused some confusing bugs when the wrong version of Yarn is used, installing a different dependency chain locally vs. CI, and then we get different behaviors in each. To avoid that, I have to disable Volta when working in projects that use Corepack, and to re-enable Volta when working in deck.gl or luma.gl.

Would others be OK with including the package.json#packageManager field here, and (if so) in other vis.gl projects? The advantage would be that we get the right version of Yarn whether we're using Volta or Corepack, as long as we keep both entries pinned to the same version.

Or' if this isn't an issue for anyone else, I can keep enabling/disabling Volta as needed, not the end of the world. :)

[coveralls]

coverage: 91.627%. remained the same
when pulling 1a149ea on donmccurdy/chore-packagejson-packageManager
into 53ca340 on master.

[felixpalmer]

I have hit this issue as well, working around it by doing npx yarn etc in the repos that expect corepack. It is certainly annoying. Can you share how you disable/enable volta so I can test?

[donmccurdy]

@felix unless there are other ways to install Volta, I think you should have lines either in .zshrc or .bashrc like this:

# VOLTA
export VOLTA_HOME="$HOME/.volta"
export PATH="$VOLTA_HOME/bin:$PATH"

To disable Volta, I'm commenting out those lines and opening a new shell session.

[ibgreen]

If there is no downside to volta usage, then this seems reasonable.

Perhaps we could abandon volta completely and align with corepack if that is an official replacement?

We do have CI tasks that use a volta github action, would that need changing to use corepack instead?

Tangentially, I might be wrong, but it seems to me that a lot of projects are moving from yarn to pnpm.

[chrisgervang]

This should also be pinned in the website and any other package.json where volta is in use. yarn threw an error in hubble.gl when packageManager was missing in website, which is yarn 1, since the top level project was pinned to yarn 4.

The two versions currently match in deck, but they can evolve separately as long as they're defined in multiple places.

[donmccurdy]

Perhaps we could abandon volta completely and align with corepack if that is an official replacement?

It does seem that corepack is what Yarn recommends. I've been happy enough with that combination in other projects. The CI would just need to run corepack enable before the installation step:

https://github.com/CartoDB/carto-api-client/blob/64da3503ccb559ac4f7f2488034d2914e57eec8e/.github/workflows/ci.yml#L34-L37

I share your impression that a lot of projects have moved to pnpm recently, but I don't have any direct experience with that.

This should also be pinned in the website and any other package.json where volta is in use

Ouch! It would be nice to reach a stage where we have Yarn workspaces (or pnpm workspaces) configured so that we can avoid skew in yarn and dependency versions. But for now, I agree pinning it in website/package.json would be necessary — added the fix!