Maël Nison

> My understanding is that corepack's npm "jumper" thing violates npm's license. I'm under the impression it's been brought to your attention in the past, and I'm pretty sure folks...

> You cannot get yarn to follow resolutions set in package.json to my knowledge -- it simply ignores them. That's incorrect. I mean, we even use them on [this very...

As mentioned in the PR that closed this issue, since it's a major change to the implementation, it won't be released in 3.x. You can already use the RCs, though,...

The global cache is now opt-in rather than opt-out in 4.x - the migration to keep the old behaviour (`enableGlobalCache: false`) should have been done automatically, but perhaps it failed...

Hello! This thread has been discussing two separate issues. - `bin` entries should be able to point to **native binaries**; we finally fixed this today in: #5508 🎉 - `bin`...

> Is there anything that is blocking a final release of Yarn 4.0.0 ? Time! It's always time. Most of the work is done, but there's always a couple of...

Will they? From the look of it they use Corepack, so if your package manager is pinned via either `packageManager` or `yarnPath`, you should only get updated PR after you...

We will have a blog post tomorrow getting into the high level changes. I'll keep the issue open until then (we just wanted to tag the release beforehand to avoid...

How can we check the logs? The [`@yarnpkg/cli` logs](https://ci.nodejs.org/job/citgm-smoker/3351/nodes=debian10-x64/testReport/junit/(root)/citgm/_yarnpkg_cli_v4_0_2/) seem unrelated to Yarn (`ConnectTimeoutError: Connect Timeout Error`), but perhaps I'm looking at the wrong place.

It seems to me this discussion is getting very off-topic. > the cache is used only when there are no loaders involved (there wasn't consensus if we wanted to also...