Skip to content

Conversation

arcanis
Copy link
Contributor

@arcanis arcanis commented Sep 29, 2020

Ranges are a tad dangerous because there's no telling which version will be installed exactly. While they are supposed to be compatible, the pros and cons are somewhat unbalanced at the moment: the risk of a regression is higher than the potential size gain, because Corepack doesn't cover npm at the moment - which is the main case where deduplication would matter.

It's better to restrict the packageManager field to strict semver versions for this first iteration and see if there's a need for ranges (which would be possible to add in a minor) than do the opposite and have to make a backward-incompatible change later down the road.

@arcanis arcanis merged commit de0bd55 into main Sep 29, 2020
@arcanis arcanis deleted the mael/semver-version-only branch September 29, 2020 23:16
@TemaSM
Copy link

TemaSM commented Nov 6, 2021

How about to add such info into Readme?
I mean, it was unexpected, that package.json should have only exact version of package manager, but not range of versions according to semver (like: pnpm@^8.0.0).
And even Nodejs docs lacks of explicitly stated info about versions ranges or strict mode for packageManager field.

@haoqunjiang
Copy link

I find it really counter-intuitive that we have an exact version in package.json. It's usually the job of lockfiles, and can be auto-updated once we run a successful yarn / pnpm install / npm install.

How about adding a packageManager field in each package manager's lockfile spec and letting corepack read that instead?

mail731212

This comment was marked as spam.

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.

4 participants