Dan Rose

> This allows omitting the version from the `package.json` `packageManager` field as well which it shouldn't do. @merceyz Why not? Please see my latest commit, which is how I feel...

> > @merceyz Why not? > > Reproducibility, if a project is installable and works today it should work in a year, if a range is used that might not...

> That command would set the `package.json#packageManager` field to a specific version of npm, not a range. That's my understanding too - I feel like I don't understand your point....

@merceyz updated the tests. I think this clarifies how I expect this to work, basically like `npm install --save-exact`, where the user can be fuzzy but the result will be...

> > Why shouldn't we trust them? It might be more important to the user to have bug fixes than to have reproducibility, especially for nascent package managers like bun....

> > @arcanis and @merceyz, would you be happy with instead [reifying the version on `corepack install`](https://github.com/nodejs/corepack/pull/300/commits/6cf4ea9bbe0cf0d2f2ed04c3b00007ba1b1fe38c) as I previously had? > > Not sure what you mean by that...

Originally reported in https://github.com/nodejs/corepack/pull/312#issuecomment-1752169602

I think there are two issues: - `yarn@*` is probably being expanded by your shell and the version of the command without the global tag doesn't take a specifier. Try...

Note this might have been at least partly obscured by TypeScript itself. Changing the dynamic `require('nblas')` to a static import `import * as nblas from 'nblas'` causes a number of...

This might be a very bad idea, but it also seems like it might be in line with the original plugin architecture intent. Curious your thoughts.