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

Add setting to specify external modules by package name pattern #1510

Closed
Blasz opened this issue Oct 21, 2019 · 4 comments · May be fixed by #1524
Closed

Add setting to specify external modules by package name pattern #1510

Blasz opened this issue Oct 21, 2019 · 4 comments · May be fixed by #1524

Comments

@Blasz
Copy link
Contributor

Blasz commented Oct 21, 2019

I'm proposing a new setting to specify external modules by a package name pattern to satisfy the following use case:

We have a monorepo consisting of multiple packages that depend on each other. We'd like to enforce that every package that is imported by another package in the same repository is listed as a dependency in package.json. We want to use the import/no-extraneous-dependencies rule to enforce this, however, we can't specify that each package in the monorepo is an external dependency because:

  1. We resolve package dependencies using a custom resolver that resolves packages to their source location
  2. Eslint detects these dependencies as internal modules because their resolved path does not fall under node_modules

In the past, our packages were scoped which resulted in them being treated as external modules because of #1293. However, since that has been fixed we now run into this problem.

The existing import/external-module-folders setting isn't sufficient for us because:

  1. Our packages don't reside as a flat list under a single directory such as node_modules
  2. The package dir name does not match the package name in all cases, especially not with scoped prefixes

Instead, a new import/external-module-patterns setting that allowed one to specify an array of string/regex patterns to match against package names, could be used to match all of our packages as external since they all share a common scope.


A second option could be to add some further metadata in the returned value from custom resolvers to specify whether a module is external or not.


Alternatively, it would be worth revisiting the decision made in #943 to only report errors for dependencies that can be resolved and provide a config option to opt-in to reporting errors for unresolved dependencies. As then, we would no longer need to mark our modules as external and would just remove our custom resolver altogether so that they are always unresolved and therefore marked as external.

@awdyson
Copy link

awdyson commented Oct 28, 2019

Appreciate this.

I'd suggest adding a field for internal module patterns as well. I'm using tilde-led aliases for paths, and it'd be nice not to treat them as unknowns.

@ValeryVS
Copy link

I'm also want this feature.

Some of my dependencies resolved as symlinks with different paths between every launch.
So, I just can't wtite correct import/external-module-folders, because it looks at path, not at package name.

@ValeryVS
Copy link

Made a PR ^. Tests included. Please look at it.

@skozin
Copy link
Contributor

skozin commented Jan 14, 2020

This seems to be related to #1597 and should be at least partially fixed by #1605 since now you can use import/external-module-folders and it will work regardless of whether dir name matches package name or not.

@ljharb ljharb closed this as completed Feb 18, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging a pull request may close this issue.

5 participants