Comments (9)
What's the difference from
corepack install -g yarn@latest pnpm@latest
?
corepack install -g yarn@latest pnpm@latest
would install whatever version has the latest tag on their relative registry (at the time of writing [email protected]
and [email protected]
), which is rarely what you want (at least, it's certainly not what you want for yarn
, the global version should always be Yarn 1.x).
corepack up -g yarn pnpm
on the other hand would bump to the latest version on whatever major is already globally installed. (e.g. if the global versions are [email protected]
and [email protected]
, it would install [email protected]
and [email protected]
).
from corepack.
Corepack is still experimental, so a regression in that way isn't necessarily to be fixed. Especially the part about "Yarn to the latest 1 and everything else to the latest major" is worth a debate. The one and only reason [email protected]
isn't what's installed by npm install -g yarn
is that it'd break older projects who happen to run npm install -g yarn
in their Dockerfile.
Since Corepack isn't used by those older projects, it doesn't have the same concerns, so it's worth really considering whether it makes sense to keep yarn@1 the default global there.
from corepack.
If I install Yarn modern globally, will Yarn classic still be used if I don't have packageManager
in a local package.json
? I'm fine with global usage, I just don't want this breaking Yarn classic projects.
from corepack.
What's the difference from corepack install -g yarn@latest pnpm@latest
?
from corepack.
I disagree this is a behavior we want to have. Package managers don't have this concept of "upgrade but stay on the same major", and I don't think we should add a whole new command just for that.
Some alternatives:
-
Document that users must make explicit the version range if they really want that (ie
corepack install -g yarn@^1
) -
Add support for a version-less range (ie
corepack install -g yarn@^
), but not a whole separate command
from corepack.
Why do we have a corepack up
command if this is not a behavior we want?
from corepack.
corepack up
is meant to update the version of the packageManager
field. In a sense it's similar to what would be install
without the -g
flag, but without needing the package name to be specified (since we already know it from the packageManager
field).
I think I implemented the "same major restriction" there because someone else requested it and semantically it made some sense to be conservative for a project with a checked-in version. I don't think it makes that much sense for the global version - if someone wants to use a specific version somewhere, they should lock it with packageManager
imo.
from corepack.
I just want to have one command that upgrades Yarn to the latest 1 and everything else to the latest major. It was removed in #351 with no documentation.
from corepack.
In my experience, most folks want to be up-to-date, but would prefer staying away from breaking changes, so I really think it makes sense to have.
it's worth really considering whether it makes sense to keep yarn@1 the default global there.
I agree it's debatable, but having this feature doesn't force anyone to use it – same way the fact that Corepack supports the "packageManager"
field, it doesn't force anyone to use it.
from corepack.
Related Issues (20)
- Corepack error with yarn on enable HOT 2
- Silent option on corepack HOT 1
- Frequent fetch() errors HOT 8
- Can't use `pnpm` via corepack when `COREPACK_HOME` is read-only. HOT 4
- feat: store `packageManager` property also inside the lock file HOT 5
- `COREPACK_INTEGRITY_KEYS` being ignored when corepack is spawned by other tools HOT 2
- Could we support corepack enable --yes? HOT 4
- `corepack install --global [email protected]` doesn't work HOT 2
- corepack installs pre-release version of pnpm `9.1.0-0` HOT 1
- CI/CD runs fail: Type Error: URL.canParse is not a function HOT 6
- corepack install verbose error HOT 4
- Corepack doesn't work properly inside official node docker images. HOT 3
- prepare and enable command is not documented HOT 2
- Add quite mode when download file HOT 1
- Metadata retrieval errors when using `COREPACK_NPM_REGISTRY` in combination with Sonatype Nexus
- `prepare` script blocks correct usage HOT 2
- I'll double-check, but the help should be printed on `corepack -h|--help`:
- Corepack and Yarn isolation in an nvm-managed environment
- `COREPACK_ENABLE_AUTO_PIN` should default to `0`
- mkshims assumes Node is globally installed HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from corepack.