You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It seems that currently no-extraneous-dependencies relies on builtin-modules to get the list of modules provided by Node.js environment. But the code could be run not only in pure Node.js environment. AWS Lambda is such example: in Lambda's code one can import aws-sdk module which is guaranteed to be provided. Therefore you don't have to have it as a dependency in your package.json file. I'll omit the discussion about good/bad practice to rely on uncertain version of something that is provided to you, because I believe that in this case plugin should be flexible enough to accommodate any practice.
I see the following options to achieve it:
have such "env provided modules" to be specified in no-extraneous-dependencies rule's configuration
file level comment in the same manner as no-undef works with /* global ... */
introduce aws-lambda ESLint env (which will extend node). Hm... what will be the next step in this case to supply info about built-in modules for the import plugin?
anything else?
The text was updated successfully, but these errors were encountered:
We could provide presets of modules to ignore based an environment in the plugin's settings, but I'm pretty sure this will be going out of hand with every framework that we see add builtin modules (aws, meteor, electron, webpack, node-webkit, babel plugins, ...).
I'd propose to either:
Add a new option (evn though this one could get a bit verbose at the rate we're going) in the rule to ignore some rules. "import/no-extraneous-dependencies": ["error", {"ignore": ["aws-sdk"]}]
Tell users to simply use // eslint-disable-line import/no-extraneous-dependencies on those lines, which would be a lot simpler to maintain. But in this case, we at least need to properly document this expectation of us.
It seems that currently
no-extraneous-dependencies
relies on builtin-modules to get the list of modules provided by Node.js environment. But the code could be run not only in pure Node.js environment. AWS Lambda is such example: in Lambda's code one can importaws-sdk
module which is guaranteed to be provided. Therefore you don't have to have it as a dependency in your package.json file. I'll omit the discussion about good/bad practice to rely on uncertain version of something that is provided to you, because I believe that in this case plugin should be flexible enough to accommodate any practice.I see the following options to achieve it:
no-extraneous-dependencies
rule's configuration/* global ... */
aws-lambda
ESLint env (which will extendnode
). Hm... what will be the next step in this case to supply info about built-in modules for the import plugin?The text was updated successfully, but these errors were encountered: