Maël Nison

That's the expected behaviour. See the documentation: > `COREPACK_ENABLE_STRICT` can be set to `0` to prevent Corepack from throwing error if the package manager does not correspond to the one...

Corepack has no knowledge of what the underlying package manager CLIs look like, and can only make trivial assumptions about it. If you want a similar behaviour, you'll need to...

This issue is about several independent feature requests ("I want to use different package managers on different commands", "I want to specify what happens when the version mismatches"). The `packageManager`...

It can be configured: > `COREPACK_ENABLE_STRICT` can be set to `0` to prevent Corepack from throwing error if the package manager does not correspond to the one defined for the...

That seems fair, you're welcome to open a PR prototyping this. To be clear, this doesn't have anything to do with removing `packageManager`, though.

> This would allow mixing and matching of package managers, for example pnpm to install packages but then Bun to run scripts. Fwiw as a package manager author that's exactly...

I think that's something you should bring up to pnpm - in the case of Yarn it isn't a problem because Yarn already adds itself to the PATH, Corepack or...

> I don't use npm, but when I do, it's through Corepack. I don't think we gain anything from this. This is certainly going to be a loss of functionality...

> I disagree, I think users should be in control. We should respect the license chose by the author of the software My line of thinking was that some basic...

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...