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

Strategy that prefers "primary" version (specified in package.json) #255

Open
joshkaplan opened this issue Dec 8, 2023 · 0 comments
Open

Comments

@joshkaplan
Copy link

Our desired deduplication strategy is for dependencies to use the "primary" version when possible (the one specified in package.json), rather than highest or fewer.

Problem

When using highest, when packages have loosely specified dependencies, introducing a new version into the tree (but not as the "primary") causes these packages to get upgraded to the newest version. This is not always desired, and can cause version mismatch issues.

For example, many packages allow @types/node: * or similarly loose versions. We specify a version of @types/node that ~aligns with the version of node we are using. But when we install/upgrade a package that asks for a higher version of @types/node, yarn-deduplicate then forces most of our other packages to use this new version, which is not what we want. At the moment, we get around this by excluding @types/node, but this is not ideal because we do want to deduplicate it.

Possible Solutions

  1. A new option called --preferPrimary or something like that. This would add a new rule that prefers the primary version where possible, and otherwise falls back to the --strategy.
  2. Similar, but implement as --strategy=primary. However, this might be a bit unclear as to what if falls back to, and not as flexible.

I'd be happy to try to draft a PR if maintainers are open to it!

@joshkaplan joshkaplan changed the title Strategy that uses "primary" version (specified in package.json) as much as possible Strategy that prefers "primary" version (specified in package.json) Dec 8, 2023
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

No branches or pull requests

2 participants
@joshkaplan and others