Closed SettingDust closed 2 months ago
I think the current lockfile was generated with Yarn classic (v1), not Berry (v2/v3).
I think the current lockfile was generated with Yarn classic (v1), not Berry (v2/v3).
ya
It's not really possible to "bundle" a package-manager with a repo. Corepack will adress this but it's still in an experimental stage the requires opt-in so it's not really feasible for real use as you can't expect developers to have it enabled.
The established "solution" OSS is afaik to document the package-manager used under the contributing
section of the readme.md
.
It's not really possible to "bundle" a package-manager with a repo. Corepack will adress this but it's still in an experimental stage the requires opt-in so it's not really feasible for real use as you can't expect developers to have it enabled.
The established "solution" OSS is afaik to document the package-manager used under the
contributing
section of thereadme.md
.
Why do something like this? Every package manager should work, no?
And if another package manager changes the package-lock.json
, just don't include the changes in the commit.
Why do something like this? Every package manager should work, no?
And if another package manager changes the
package-lock.json
, just don't include the changes in the commit.
In some situation package url will different with the same package manifest.
I stand corrected, however that's a "feature" of Yarn Berry that also requires the PnP feature of Yarn Berry to be utilised.
I stand corrected, however that's a "feature" of Yarn Berry that also requires the PnP feature of Yarn Berry to be utilised.
Noop. It's a feature of yarn. And needn't pnp. PnP is for actually zero install. But specific the yarn version or bundle the yarn is what I said
Which just need yarn set version <version>
.
Seems my yarn 3 break the lock file when import the project