`COREPACK_ENABLE_AUTO_PIN` should default to `0`
benmccann opened this issue · 16 comments
I don't want to use corepack. However, this setting means that every single contributor to my project will need to set COREPACK_ENABLE_AUTO_PIN=0 and be careful not to accidentally check in the packageManager field since corepack will automatically add that field to force itself upon any project you use. This is even more annoying since pnpm can't be used without corepack once the packageManager field is present: pnpm/pnpm#8087
Same thing here.
I have projects that use pnpm, some don't, some require pinning the version and others don't.
I think nobody wants their package.json to be automatically modified on any command one could do. And even less on packages you do not own.
I do NOT want to add this field on packages I do not own just because I contributed to it for a small fix or something.
Discoverability of such a feature is also bad, especially for juniors that will 100% fail to understand the implications of the new field and how to disable the feature (the env variable is not even part of the upgrade message). For sure we'll be getting PRs on many projects adding the field with random versions the others might have installed at the moment they made their fix, and it'll create unnecessary back and forth to ask to remove it.
This is even worse because in some of my use cases, the package.json happens to be readonly (for reasons out of my control), and so it will fail while all I asked was the equivalent of npm ci npm install -save=false, pnpm --frozen-lockfile or any such command that should not touch files. Which I explicitly use because I do not want to touch neither the package.json nor the lock file!
Note that it can (and should) in my opinion be fixed before the next version of node is released or the problem will most likely blow up.
For reference this was added by #413 in version 0.26. Original issue was #399.
I think that a warning can be printed by default instead of directly modifying the package.json.
I also believe that this should be disabled by default.
If we have to synchronize this environment variable within the team to prevent everyone from enabling it, that would be terrible.
At least allow it to be set in npmrc instead of an environment variable so project managers can force it off for everyone.
For me its another use case. I create a lot or demos, samples and help students with their code. I don't know the environment of each person, and I deal with a lot of different repositories and companies.
Creating this packageManager by default, once I enabled corepack only on my machine, requires everyone to have the exact same package manager (including version) that I have on my computer. This leads to a awful developer experience for trying to running a demo, sample or a open source project for the first time.
Yes, having an option to disable on .npmrc or something would be nice, but in most cases this leads to having more files then I honest need on my repo, that in my use cases I prefer to KISS.
I did set COREPACK_ENABLE_AUTO_PIN to 0 so it doesn't botter me anymore, but I don't think this is the ideal solution.
there're other monorepo tools like Rush which support pin packageManager version without using corepack, when run pnpm commands in these tools, the auto pin behavior may make inconsistent version than the version specified by monorepo tools.
I've run into the same issue. I've wrote about my case here, maybe someone also runs into this:
https://blog.hyperknot.com/p/corepacks-packagemanager-field
Happy New Year! What is the response of maintainers on this?
Perhaps we could have an option of setting "packageManager": null which would effectively be equivalent of having COREPACK_ENABLE_AUTO_PIN = 0 but on a project level instead of user level.
Committing that should effectively prevent corepack from ever writing the packageManager into package.json field and simply treat it the same as COREPACK_ENABLE_AUTO_PIN = 0 in the project for every developer.
Unfortunately I suspect this won't be backwards compatible with older corepack versions which would just overwrite the current packageManager value (including null).
The default value of COREPACK_ENABLE_AUTO_PIN allowing Corepack to autopin is a barrier to adoption of Corepack in a mixed environment contributing to Yarn repos whilst still dealing with Yarn Classic repos which have not transitioned to Corepack.
If I execute yarn -v in a Yarn 1 Classic repo that I don't own and which has no packageManager field set in its package.json file, I don't want corepack to add one for me. As far as the repo is concerned, I would like yarn -v to be a read-only command. By default however, if corepack is enabled, it is not read-only.
I would like to have corepack permanently enabled for Yarn, however this situation means that I am enabling and disabling corepack instead as a workaround, which causes other difficulties, as the corepack enable / corepack disable sequence does not save and restore the links to any globally installed Yarn Classic version (see #112). Yarn Classic is still there in the node directory, however it is no longer linked and essentially needs to be re-installed to get the link back.
I would also like to see COREPACK_ENABLE_AUTO_PIN set to 0 by default, for the above reasons.
- The functionality was added in PR #413
I wonder if it could simply be made a requirement for those packages which consciously want to opt-in to corepack, for them to add a desired packageManager version with corepack use? Automating it is causing issues with repos that are older or consciously have not opted in to corepack.
If I remember correctly, PR #413 was implemented at the request of the Node.js TSC after several meetings trying to figure out if corepack should be made stable as part of the node distribution.
I think if corepack is made stable, then it makes a lot of sense to keep it as-is.
But it seems we're not trending in that direction since others on the TSC want to remove corepack from the node distribution.
Sidenote, just wondering why packageManager was not just a hint with ^ caret to indicate the minimum minor version instead of a pinned exact version?
And why the SHA of exact version is not in the lock file, since that's what the lock file is for?
Just like Node packages...
Just to add - I can see that corepack is experimental and needs to be opted in - if this is the case why is it doing anything? I have upgraded to node 20 and I get this behaviour by default without enabling anything.
Just to add - I can see that corepack is experimental and needs to be opted in - if this is the case why is it doing anything? I have upgraded to node 20 and I get this behaviour by default without enabling anything.
Would you like to open a new issue and say which operating system you are using and how you installed Node.js? As you say, Corepack is not supposed to be enabled by default.
Yeah, sorry, I should have realized this is a completely different issue! I have already disabled corepack but will have folks with similar setup to mine so we'll try to get more info on the topic and move to new issue. I'm on macOS and using nvm to install node.
Just to add - I can see that corepack is experimental and needs to be opted in - if this is the case why is it doing anything? I have upgraded to node 20 and I get this behaviour by default without enabling anything.
Yeah, sorry, I should have realized this is a completely different issue! I have already disabled corepack but will have folks with similar setup to mine so we'll try to get more info on the topic and move to new issue. I'm on macOS and using nvm to install node.
@apieceofbart it looks like you didn't get around to opening a separate issue. I ran into this too, so I wanted to drop a line here in case other folks run into it too.
I never explicitly enabled Corepack, but when I upgraded my Node.js version, Corepack was unexpectedly enabled and it started pinning the package manager as described in this issue.
It turns out that nvm is automatically enabling Corepack when you use the --reinstall-packages-from argument. Perhaps you did the same? I filed a bug in the nvm repo: nvm-sh/nvm#3544
EDIT: the maintainer just published a fix in nvm v0.40.2 🎉
@jportner thank you! I didn't follow up because it seems that no one else had that problem and I had trouble reproducing.
You're spot on - I did run --reinstall-packages-from after bumping node via nvm so that's definitely the same case. Great job finding this out!