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

How to prevent from running npm install in pnpm or yarn projects? #674

Closed
zanminkian opened this issue Mar 12, 2025 · 9 comments
Closed

Comments

@zanminkian
Copy link

Since corepack does not support npm, it's always possible to run a npm command within a project configured to be used with another package manager.
For example, a package.json has been configured "packageManager":"[email protected]". People can stil run npm install in this project.

I know @antfu/ni and #650 can help. I also know corepack is going to completely remove ALL code about npm. However, for a better development experience, it is widely expected to throw an error when running npm install in pnpm/yarn projects.

Any solutions?

@legobeat
Copy link

legobeat commented Mar 12, 2025

Do I understand right if you wish to prevent developers from running installation with anything but your specified package manager? If so it doesn't seem like anything core pack could support per se as the entrypoint in case is npm. corepack is primarily a package-manager bridge, not a script executor.

How about a preinstall script which bails unless your conditions are met? if nothing else, you should be able to look at environment variables to detect initiating package manager(s).

@aduh95
Copy link
Contributor

aduh95 commented Mar 12, 2025

You can use "devEngines": https://docs.npmjs.com/cli/v11/configuring-npm/package-json#devengines

@zanminkian
Copy link
Author

You can use "devEngines"

It can help. Thanks. But...still looks weird. This propery is not widely supported by yarn and pnpm. A package.json containing both packageManager and devEngines looks verbose 🤦

@aduh95
Copy link
Contributor

aduh95 commented Mar 13, 2025

Unfortunately npm team made it very clear they would always disregard the packageManager field, and that's how the devEngines proposal got traction. Technically you could use only devEngines with latest Corepack.
I've suggested in #668 to move the packageManager field to a separate file, but I didn't receive much support for this idea, so currently that's not an option.

@zanminkian
Copy link
Author

Npm do not and won't support packageManager field. So I suggest corepack support devEngines when packageManager is not present. For example, a package.json contains devEngines but not packageManager. Running pnpm and yarn should respect devEngines, but currently it will automactically insert a packageManager field.

@aduh95
Copy link
Contributor

aduh95 commented Mar 13, 2025

So I suggest corepack support devEngines when packageManager is not present. For example, a package.json contains devEngines but not packageManager

That's already the case, see https://github.com/nodejs/corepack?tab=readme-ov-file#devenginespackagemanager

currently it will automactically insert a packageManager field.

Only if devEngines doesn't specify a specific version

@zanminkian
Copy link
Author

zanminkian commented Mar 13, 2025

@aduh95 Awsome. I forgot I am using corepack v0.31.0. Thanks!

Since corepack released v0.32.0, I think we can deprecate packageManager field now. Using devEngines works well under both npm(>=10.9.0) and corepack(>=0.32.0).

@arcanis
Copy link
Contributor

arcanis commented Mar 13, 2025

I think we can deprecate packageManager field now.

Certainly not. We have no plan to add support for devEngines in Yarn.

@zanminkian
Copy link
Author

FYI, I use yarn or pnpm via corepack. So personally, I don't need packageManager field since npm and corepack support devEngines.

Deprecating something that has already documented in official Node website is a serious thing.

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

4 participants