Eslint-plugin-import: no-extraneous-dependencies: autofix

[benmosher]

My expectations for this are:

1. it must be configured explicitly via some rule config option, since it makes external modifications
   
   
   
   • i.e., if you use autofix and this rule, it won't attempt installs _unless_ you've enabled it explicitly
   
   
2. it calls npm install [package] vs. mutating the package.json directly
   
   
   
   • as such, if it is extraneous _and_ you haven't installed it, you get all the dependencies
   
   
3. aforementioned rule config is something like install: 'SE' meaning the fix call is npm i [dep] -SE.

I can imagine changing position on (1) and (3) on account of .npmrc existing. Perhaps its existence qualifies as "explicit config".

Note that this means that if your editor has linter integration and autofix enabled on save, you could npm install simply by adding an import/require statement to code.

Would be pretty sweet. Essentially an alternate ESLint-powered form of npm-install-webpack-plugin at that point.

cc-ing @jfmengels as author of no-extra-deps and @sindresorhus for +1-ing my comment about this on the original rule issue.

[jfmengels]

Love the idea, just a few worries I have that I'd like to mention:

Does ESLint handle async operations well? All the APIs ESLint provides look very sync. We could just spawn the install command, but if we could have several, that'd be nice. Also, if the operation fails (no Internet for instance), should it warn/throw something?

Note that this means that if your editor has linter integration and autofix enabled on save, you could npm install simply by adding an import/require statement to code.

Worried that it will trigger plenty of calls if file is saved multiple times. Not very harmful per se, but not really nice.

:+1: on points 1.
:+1: on point 2 too, though I'd like to add that the rule should install multiple missing dependencies in one command (npm i [package1] [package2]) if several packages are missing.
:+1: on points 3, though the option should include the dashes (-SE). That way, people can do --save-dev without us having to explain what each option is, and is clearer for people who look at the .eslintrc file.

[benmosher]

Yeah, ESLint is synchronous through and through, and for good reason. It's not really meant for most of the things this plugin does already. 😅

Aggregating the necessary calls and then blasting all at once is a good call. Ideally, would install once per ESLint process vs. once per linted file, even.

Worried that it will trigger plenty of calls if file is saved multiple times.

Yeah, that's fair. Probably some way to avoid this with some sort of FS locking (if some file exists, don't spawn install). Worth considering, but I don't think it blocks any experimental implementation.

I can imagine just doing the spawn with async functions and just accepting that there won't be any failure notification. I don't know what the feedback would even be, save for just writing to stderr.

[sindresorhus]

I so want this 🎉