eslint-plugin-import Wildcard support in `import/core-modules`

Feature request:

Allow wildcards in the import/core-modules settings

      "settings": {
        "import/core-modules": [
          "@my-monorepo-namespace/*",
        ]
      }

... so that

        "import/no-extraneous-dependencies": ["error", {"devDependencies": true}]

...does not throw an error for modules within a certain namespace.

Why?

I have a monorepo structure where we can safely assume that anything within a certain namespace is available and doesn't need to be listed in devDependencies. I would rather not maintain lists of packages and versions manually.

Feb 06 '19 17:02 penx

It'd only be names, not versions; how many packages do you expect to have under the namespace that listing them manually is difficult?

(Also note, you can always dynamically create a config that builds up the list of names for you)

Feb 06 '19 20:02 ljharb

We have one package per React component. There are reasons we don't want to maintain a list beyond maintenance/size of the list - we don't want these libraries in devDependencies due to causing lerna publishing issues, and this error would encourage a developer of a new component to add the dependency in to devDependencies rather than edit the list in eslint config. I'd rather there wasn't an eslint config maintenance step when a new component is added.

Dynamically generating a list would probably be a better option for us, which I had considered but I was concerned about reading package names from many package.json files on disk whenever eslintrs.js is loaded, and whether this would have a noticeable effect on some IDEs/plugins (I haven't looked in to caching/how often IDEs would load from disk).

I figured wildcard support would be an easy way to solve this and may be a useful feature to have regardless. We should be able to find another solution if not.

Feb 06 '19 21:02 penx

On a side note, we previously worked around our publishing issue by maintaining the list in the root package.json

    "@govuk-react/error-text": "*",
	    "@govuk-react/file-upload": "*",
	    "@govuk-react/grid-col": "*",
	    "@govuk-react/grid-row": "*",
	    "@govuk-react/header": "*",
	    "@govuk-react/hidden-text": "*",

But then we came to do an alpha release, realised * doesn't map to -alpha and the whole system broke down 😄

https://github.com/govuk-react/govuk-react/pull/536/commits/a90540a7b2612ab6fa5e35970b9100d564666f8d

(this commit has a working alternative solution)

Feb 06 '19 21:02 penx

Thanks for explaining. I think I could get behind allowing a single asterisk at the end, to cover this use case.

Feb 06 '19 21:02 ljharb

Just a quick note - it seems that when updating to the latest eslint and eslint-plugin-import the solution that we had used on govuk-react to add the modules to the import/core-modules list no longer completely works

Sep 11 '19 12:09 stevesims

The same problem arises when having something like this:

// eslint config
"import/core-modules": ["my-module"]

// code
import x from "my-module/x";

This will cause a 'my-module' shoudl be listed ... error. The check done here:

if (coreSet != null && coreSet.has(modulePath)) return { found: true, path: null }

Matches my-module/x against my-module. I guess It should check just the module name, not the full path.

I'm not sure if a change here could end breaking everything else. just took a few glimpses of the source code 😅. Seems that a wildcard matching should fix both problems.

We also share @penx problem in several projects where we have several prefix-name named packages, and the number of those packages tend to increase. It would be very nice to just add prefix-* to the import/core-modules rule.

Sep 27 '19 09:09 davidbarral

is any update on this issue ? @ljharb

Feb 24 '20 03:02 linxiaowu66

I'd be happy to accept a PR for https://github.com/benmosher/eslint-plugin-import/issues/1281#issuecomment-461200205

Feb 26 '20 00:02 ljharb

any updates on the the issue?

Jun 07 '20 01:06 hamzahamidi

Nope, nobody's sent a PR yet.

Jun 07 '20 02:06 ljharb

Hey guys, I met the same problem too:

// "@utils" is an alias module for webpack resolver
import '@utils/fetch'; // eslint error

I opened an PR to solve the it: https://github.com/benmosher/eslint-plugin-import/pull/1999

Mar 06 '21 08:03 southerncross

Hey guys, I met the same problem too:
// "@utils" is an alias module for webpack resolver
import '@utils/fetch'; // eslint error
I opened an PR to solve the it: #1999

Sorry, I misunderstood the problem, the PR had been closed...

Mar 08 '21 06:03 southerncross

Reviving this thread. PR created. Thanks @davidbarral for the pointer. @penx have a look. I won't likely be too available to back-and-forth with the maintainers here so feel free to take over :)