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

no-extraneous-dependencies: ability to extend the list of built-in/provided modules #433

Closed
ikornienko opened this issue Jul 12, 2016 · 3 comments

Comments

@ikornienko
Copy link

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?
@jfmengels
Copy link
Collaborator

Sounds like something close to #283.

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.

What do you think @benmosher?

@benmosher
Copy link
Member

benmosher commented Jul 12, 2016

Is this not solved already by the import/core-modules setting?

e.g.

// .eslintrc.js
exports.settings = {
  "import/core-modules": ["aws-sdk"],
}

IIRC I updated importType to consider it, so I think no-extraneous-dependencies should respect it.

@ikornienko
Copy link
Author

Oh, sorry, I overlooked this setting... Thanks a lot, @benmosher, it indeed solved the case!

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

No branches or pull requests

3 participants