eslint-plugin-import
eslint-plugin-import copied to clipboard
import-js
User's package manager isn't npm and as a result doesn't recognize suggested command when not using npm
Link to where in the code the error message is being generated: https://github.com/import-js/eslint-plugin-import/blob/d8633c35ba7031eb49b2a36b27c82b289f8f85ce/src/rules/no-extraneous-dependencies.js#L106
Image of error output. The error message format is because I'm using Trunk Check CLI, a superlinter, and the ESLint error I'm referring to is the one that says "14:17 high 'axios' should be listed in the project's dependencies. Run 'npm i -S axios' to add it". Notice the error when I try to run that npm command:
Suggestion: Add configuration toggle for the user's package manager
npm ships with node, so it should always be present.
Separately, if a user is choosing to use a nonstandard package manager, they already have to "just know" how to translate npm commands into their own CLI, so they can understand "almost all the documentation on the internet" - i'm not sure it's worth adding this complexity here to account for this.
We're running into this issue as well. We are using yarn and when folks are following the rule npm i -S axios, it introduces package-lock.json and messes up nested node_modules directories in our monorepo.
I'd recommend a customizable message at least, similar to what ESLint does for no-restricted-globals: https://github.com/eslint/eslint/issues/8400
@tronguye regardless, you need a way in your repo to prevent people from using npm, because even if this project doesn't mention it, most tutorials, readmes, and docs on the internet will.
Once you have that mechanism (engines.npm set to something unsatisfiable, for example), then this project's messaging doesn't matter.
We definitely should not be considering a field used by an experimental tool that may not continue to be shipped in node.
We definitely should not be considering a field used by an experimental tool that may not continue to be shipped in node.
If it is defined by the user, then the user is using it. I don't think experimental matters in this case. 🤔
Either way, I think that users of a nonstandard package manager are already forced to learn how to conceptually map npm commands to their preferred package manager's commands (https://github.com/import-js/eslint-plugin-import/issues/2434#issuecomment-1097046365)
If there is the insistence on having overly detailed resolution output, I'm not sure why there is resistance to supporting customizable messages? It would allow the default behavior to persist while letting consumers override the overly prescriptive resolution directives.
