Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: Implement package.json#packageManager field #3036

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

kouak
Copy link
Contributor

@kouak kouak commented Jun 26, 2024

Corepack appears to be the emerging tool to pin a specific package manager version.

Corepack is now distributed with node, and uses the package.json#packageManager field : https://nodejs.org/api/packages.html#packagemanager

This PR adds the packageManager field, aligned with volta.yarn.

@kouak kouak changed the title (chore): Implement package.json#packageManager field chore: Implement package.json#packageManager field Jun 26, 2024
Copy link
Collaborator

@ibgreen ibgreen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some concerns are that:

  • The organization of package.json files in vis.gl repositories is aligned, so if we make a change here, we probably should be making it across all repos (deck.gl, luma.gl, math.gl, etc etc)
  • We already use volta to control package manager, so we are adding a separate mechanism for node only. In what cases is this beneficial?
  • When someone upgrades the yarn version, how do they find the SHAs of the new version?
  • And finally what does this actually control? How is node involved in package management? What node command delegates to the package manager specified here.

@kouak
Copy link
Contributor Author

kouak commented Jun 26, 2024

corepack replaces the package manager part of volta

If all team members use volta and are fine with it, then this is redundant. This is beneficial to external contributors who might not have volta installed on their system but are more likely to have corepack enabled on their system IMO (since corepack is distributed alongside node).

When enabling corepack on a system (via corepack enable), corepack will create pnpm and yarn binaries and intercept all calls.

When yarn or pnpm is called in a project, corepack will automatically download and cache the proper package manager version :

image

To update to a specific yarn version, maintainers should run corepack use yarn@4.2.2 in the repo.

To update to the latest yarn version : corepack up.

On corepack enabled systems, corepack will try to set the package.json#packageManager field if its not present.

Corepack works fine without the sha :

{
  "packageManager": "yarn@4.2.2"
}

There's an upcoming vote in Node Technical Steering Committee about whether future node versions should enable corepack by default (and thus, install yarn and pnpm binaries, managed by corepack).

We just migrated our team at work from volta to corepack + fnm and we've found the developer experience to be similar or better. We're building a dockerized app though, and because corepack is bundled with node, corepack is also present in official node docker images. In our case, this ensures that our artefacts also use the same package manager version.

This might not be relevant to the vis.gl repos though, so feel free to close this PR in that case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants