Add option for ignoring `no-extraneous-dependencies` by package name

[SnO2WMaN]

I think there should be an option in import/no-extraneous-dependencies to exclude by package name for such as non-explicitly in package.json sub dependency.

For example @storybook/addon-actions that normally and should be added as sub dependency of @storybook/addon-essentials. In this situation, adding ignore comment for every stories file is unrealistic I think.

Sorry if this can already be set, or if this is an Issue that already exists.

[mutantcornholio]

My case is that I'm importing types from, for example @types/aws-lambda, like this:

// this is a type import, it'll dissapear in the built code
// eslint-disable-next-line import/no-extraneous-dependencies
import { SQSEvent } from 'aws-lambda';

It'd make my life easier to be able to ignore import/no-extraneous-dependencies errors for package @types/aws-lambda (or aws-lambda, not sure how that part works)

[ljharb]

@mutantcornholio use import type

[mutantcornholio]

Hmm, somehow I thought that import type is something from Flow and doesn't work in TS, but... thanks :)

[nicolo-ribaudo]

+1 for this feature request. In my case, we have a specific dependency (charcodes) that is always inlined at compile (through babel-plugin-transform-charcodes time and thus it should not be in dependencies. For all other imports, I need this rule to make sure that I am including them in dependencies and I'm not just accidentally relying on them due to them being present in my transitive dependencies.

Ideally, I'd like something like the following:

    rules: {
      "import/no-extraneous-dependencies": [
        "error",
        { devDependencies: false, ignore: ["charcodes"] },
      ],
    },

I'm happy to open a PR if it's something that would be accepted.

[ljharb]

@nicolo-ribaudo by not including that in dependencies, you've deprived consumers of being able to construct an accurate SBOM or detect when charcodes has a CVE or a license conflict. "dependencies" is for all conceptual runtime deps, not just the things that end up used directly from node_modules.