Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

COREPACK_ENABLE_AUTO_PIN should default to 0 #485

Open
benmccann opened this issue May 28, 2024 · 6 comments
Open

COREPACK_ENABLE_AUTO_PIN should default to 0 #485

benmccann opened this issue May 28, 2024 · 6 comments

Comments

@benmccann
Copy link

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

@Lectem
Copy link

Lectem commented Jul 14, 2024

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!

@Lectem
Copy link

Lectem commented Jul 14, 2024

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.

@AprilNEA
Copy link

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.

@KaelWD
Copy link

KaelWD commented Jul 26, 2024

At least allow it to be set in npmrc instead of an environment variable so project managers can force it off for everyone.

@vtnorton
Copy link

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.

@hardfist
Copy link

hardfist commented Aug 23, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants