Utility function to generate ignore patterns

[ark120202]

Now that 2.0.0 requires all linted files to be included in projects it became even more important to ensure that eslint processes only actual source files. Today it's done with a .eslintignore file, but it can be quite hard to manage for projects with complex TypeScript configurations. Soon it would be possible to define ignored patterns in eslint config - eslint/eslint#12274, which means it can be generated from actual patterns used to create programs. That also may simplify transition from TSLint, which processed only files included in tsconfig by default.

The new API could look like:

const { createIgnorePatterns } = require('@typescript-eslint/parser');
// function createIgnorePatterns(project: string | string[], tsconfigRootDir?: string): string[];

const project = [
  './project1/tsconfig.json',
  './project2/tsconfig.json',
];

module.exports = {
  ignorePatterns: createIgnorePatterns(project),
  parserOptions: { project },
};

[JoshuaKGoldberg]

@bradzacher before I start working on this one, just making sure - is this still something you're 👍 on? I personally am.

[bradzacher]

Yeah sounds good. I guess exported from the utils package?

Eventually I'd want it in our "core" package we use for flat configs.

[JoshuaKGoldberg]

from the utils package

Hmm, most users don't take a direct dependency on that. I think it'd be simpler to export from parser, no?

There's actually some nontrivial logic here to account for path relativity. From https://eslint.org/docs/latest/user-guide/configuring/ignoring-code#ignorepatterns-in-config-files:

• Glob patterns in ignorePatterns are relative to the directory that the config file is placed in.
  ...
  If a glob pattern starts with /, the pattern is relative to the base directory of the config file. For example, /foo.js in lib/.eslintrc.json matches to lib/foo.js but not lib/subdir/foo.js.

So I'll leave this for a while if someone else wants to take it on. 😄

[bradzacher]

Most users don't, no, as it's not necessary for config files.
I'd probably just hold off on this until we build our flat config tooling then?
Then we can create a user-focused package with all our tooling bundled up and some utils to make things easier?

[JoshuaKGoldberg]

Yeah that makes sense. And the fact that 0 users have 👍d this issue or filed duplicates of it since September 2019 indicates to me that it's not a common request. Closing for the same reasons as #5908: there's no strong user demand to be met right now.