Wildcard support in `import/core-modules`

[penx]

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.

[ljharb]

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)

[penx]

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.

[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 😄

govuk-react/govuk-react@a90540a

(this commit has a working alternative solution)

[ljharb]

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

[stevesims]

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

[davidbarral]

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.

[linxiaowu66]

is any update on this issue ? @ljharb

[ljharb]

I'd be happy to accept a PR for #1281 (comment)

[hamzahamidi]

any updates on the the issue?

[ljharb]

Nope, nobody's sent a PR yet.

[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

[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...

[anthonyp-usafacts]

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 :)