Support RegExp in `ignore` option of `no-unresolved`

[regseb]

An array of RegExp pattern strings must be set to the ignore option of the import/no-unresolved rule. With a string, linters (and text editors) don't know that it contains a regex and can't check it.

It would be simpler and safer if we could set the RegExp directly:

export default [{
  rules: {
    "import/no-unresolved": ["error", { ignore: [/\.img$/v] }],
  }
]};

[ljharb]

Supporting regular expressions in an eslint config is a CVE magnet, and a very bad idea.

What would linters be checking?

[regseb]

ESLint configuration is written in JavaScript. You can already use RegExp in the configuration:

export default [{
  rules: {
    "import/no-unresolved": ["error", { ignore: [/\.img$/.source] }],
  }
]};

It's cumbersome to write a RegExp, convert it to a string (using .source), and then convert it back to a RegExp (in eslint-module-utils).

eslint-plugin-unicorn supports RegExp in the ignore option of the catch-error-name rule.

---

I check my ESLint configuration with ESLint, which has a few rules on RegExp. And I have plugins that add others, such as eslint-plugin-regexp.

For example, in this configuration, I don't get a warning by regexp/no-dupe-disjunctions that the jpg extension is present twice (oops, I forgot the e in jpeg).

export default [{
  rules: {
    "import/no-unresolved": ["error", { ignore: ["\\.(png|jpg|gif|webp|jpg)$"] }],
  }
]};

[ljharb]

In flat config, yes - not so in eslintrc. Either way, allowing regexp is a footgun because of the CVE potential (whether it's initially a string or not).

The only patterns that I'd see accepting are globs.

[regseb]

You can add an ignoreGlob option: an array of glob strings. To avoid a breaking change, you deprecate the ignore option. And in eslint-module-utils, you filter on both lists (ignoreGlob and ignore).

And you can do the same for the setting import/ignore.

[ljharb]

Sure, that would be fine (i'd call it ignorePatterns, though)