Repository navigation
COREPACK_ENABLE_AUTO_PIN should default to 0 #485
Description
Activity
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.jsonhappens to be readonly (for reasons out of my control), and so it will fail while all I asked was the equivalent ofnpm cinpm install -save=false,pnpm --frozen-lockfileor any such command that should not touch files. Which I explicitly use because I do not want to touch neither thepackage.jsonnor 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.Reacted by Antony FagundezI 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.
Reacted by Tas, Steven, Danny Ahn and BearBinFor 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
packageManagerby 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
.npmrcor 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_PINto0so it doesn't botter me anymore, but I don't think this is the ideal solution.Reacted by Clément Grégoire, Sergey Korsik, Oleh Vanin and Tasthere'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-fieldHappy New Year! What is the response of maintainers on this?
Perhaps we could have an option of setting
"packageManager": nullwhich would effectively be equivalent of havingCOREPACK_ENABLE_AUTO_PIN = 0but on a project level instead of user level.Committing that should effectively prevent corepack from ever writing the
packageManagerintopackage.jsonfield and simply treat it the same asCOREPACK_ENABLE_AUTO_PIN = 0in the project for every developer.Unfortunately I suspect this won't be backwards compatible with older corepack versions which would just overwrite the current
packageManagervalue (includingnull).Reacted by Steven and Antoine du HamelThe default value of
COREPACK_ENABLE_AUTO_PINallowing 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 -vin a Yarn 1 Classic repo that I don't own and which has nopackageManagerfield set in itspackage.jsonfile, I don't want corepack to add one for me. As far as the repo is concerned, I would likeyarn -vto 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 disablesequence does not save and restore the links to any globally installed Yarn Classic version (see #112). Yarn Classic is still there in thenodedirectory, 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_PINset to0by default, for the above reasons.- The functionality was added in PR feat: Pins the package manager as it's used for the first time #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
packageManagerversion withcorepack use? Automating it is causing issues with repos that are older or consciously have not opted in to corepack.Reacted by Frieder BluemleIf 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
packageManagerwas 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...
Reacted by Christian, λ🏺, Shinebayar G and Justis BlascoJust 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.
Reacted by Mike McCready and 阿菜 CaiJust 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
nvmis automatically enabling Corepack when you use the--reinstall-packages-fromargument. Perhaps you did the same? I filed a bug in thenvmrepo: nvm-sh/nvm#3544EDIT: the maintainer just published a fix in
nvmv0.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-fromafter bumping node vianvmso that's definitely the same case. Great job finding this out!Reacted by Joe PortnerThis change should be made before 1.0.0 as per #687 (comment)
Reacted by Steven and Mike McCreadywhere can i set my COREPACK_ENABLE_AUTO_PIN ? or how can i set it, thats the nquestion
Update to corepack@0.33.0 to change the default to
COREPACK_ENABLE_AUTO_PIN=0(disabled)Reacted by Nathan Bierema, Kirill Groshkov, Jake Hartman, 御风, Jeong Woo Chang, Frieder Bluemle and logonoffReacted by Karl Horky
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=0and be careful not to accidentally check in thepackageManagerfield 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 thepackageManagerfield is present: pnpm/pnpm#8087