Enhancement: Allow altering the file names that project: true searches for

[JoshuaKGoldberg]

Before You File a Proposal Please Confirm You Have Done The Following...

• I have searched for related issues and found none that match my proposal.
• I have searched the current rule list and found no rules that match my proposal.
• I have read the FAQ and my problem is not listed.

Relevant Package

parser

My proposal is suitable for this project

• I believe my proposal would be useful to the broader TypeScript community (meaning it is not a niche proposal).

Description

Currently, the project: true option allows TypeScript-ESLint to auto-detect the tsconfig.json file within each package of a monorepo, however a relatively common setup is to use a tsconfig.eslint.json file for eslint setup. This means that instead of being able to utilise project: true, each package needs an eslintrc file that points to the project file, or globs need to be used in the base configuration. Neither of these are ideal either for massive duplication reasons or for performance reasons.

Ideally, another option would be added to allow setting the filename that the parser looks for when project is set to true. This would allow utilising a tsconfig.eslint.json file without needing to manually define it in all used locations.

Additional Info

This is a repost of @me4502's #7056 to avoid many comments. The comments dig into how to avoid needing this scenario in the first place. They're a good read!

[JoshuaKGoldberg]

Following up: in #6754 we added an EXPERIMENTAL_useProjectService flag that acts much more like an IDE (it uses the same "project service" APIs internally). Documenting it is tracked in #7349 and #7350.

Since that flag is experimental -and will be for quite some time-, we still don't have a stable way for situations where tsconfig.json shouldn't include JS files. Which is actually not unusual in the wild - many projects have standardized on explicitly not allowing non-TS files in the root tsconfig.json.

At any rate, I think we'd want to see an API suggestion before marking this as purely accepting prs. What would this look like in an ESLint config file? In #101 (comment), @bradzacher suggested:

• project: true - just use the closest tsconfig.json on disk for each linted file.
• project: { allowedTsconfigNames: FileName[], ignoredTsconfigs: RelativePath[] }
  • allowedTsconfigNames to specify the set of names you want us to search (default ['tsconfig.json']
  • ignoredTsconfigs to ignore specific tsconfigs you know would be useless.

I like that idea. Maybe, include: [...] and ignore: [...] for simplicity?

On the other hand, it could get confusing having this object shape have true-style lookups enabled while string and string[] shapes have it disabled. Maybe we should have an explicit relative: boolean flag in there?

project: {
  ignore: ['./packages/ignore-me/tsconfig.json'],
  include: ['tsconfig.eslint.json', 'tsconfig.json'],
  relative: true,
}

edit: switched from allowed & ignored to include & ignore... I'm not 100% on this naming...

[bradzacher]

As we look towards our language service future - the question I'd have is if people have these weird setups that require include/exclude lists to make them work - how do they work within their IDE where it doesn't have that same config?

Ideally considering we're using the same infra that the IDE supports - we should work "out of the box" in exactly the same way that the IDE works and have the same config that they have.

[bradzacher]

In terms of the here and now - I wonder if this is something we should be doing?
I wonder if true (relative resolution) should be made more complicated rather than just saying "hey if you use true then just use tsconfig.json, and if you need more complex setups then fully specify the config".

I'm of two minds as I don't know if there's a really clean way to do this "relative name plus relative lookup" config in a way that wouldn't just add more complexity to the config than if the user had manually specified things.

[saltman424]

Copying over my proposals from #7943

1. project: { nearest: string | string[] }. E.g. project: { nearest: 'tsconfig.eslint.json' } or project: { nearest: [ 'tsconfig.json', 'tsconfig.eslint.json' ] }
   • Based on the suggestions above, this could also be extended further to project: { nearest: string | string[], ignore?: string[] }
2. And/or modify the default logic of project: true to also pick up tsconfig.eslint.json files, since that seems to be the advised naming convention (e.g. as seen here)

[JoshuaKGoldberg]

I quite like { ignore?: string[]; nearest: string | string[] }. It has a nice symmetry with the boolean | ProjectServiceOptions style API in #7752. I'd be in favor of implementing this as the last (for now) addition to project: true before we go all-in on the project service.

[Samuel-Therrien-Beslogic]

I really like the idea of nearest. With a preference from top to bottom, our shared configs could go from:

"parserOptions": {
  // TODO: Try "project": true https://typescript-eslint.io/blog/parser-options-project-true/
  // This wouldn't work for tsconfig.spec.ts though
  // https://typescript-eslint.io/blog/parser-options-project-true/#investigating-custom-tsconfig-names
  "project": [
    "tsconfig?(.*).json",
    "projects/*/tsconfig?(.*).json",
    "*/tsconfig?(.*).json" // For example: e2e/tsconfig.json
  ],
  // TODO: Consider use a tsconfig.eslint.json instead
  // https://github.com/typescript-eslint/typescript-eslint/blob/main/packages/parser/README.md#parseroptionscreatedefaultprogram
  "deprecated__createDefaultProgram": true,

to: (trying to use the widest tsconfig first to reduce the number of Programs)

"parserOptions": {
  "project": {
    nearest: [
      "tsconfig.eslint.json", // pickup *all* files to be linted
      "tsconfig.editor.json", // pickup *all* project files to get import suggestions in editor, created by nx
      "tsconfig.app.json", // Angular base
      "tsconfig.spec.json", // jest
      "tsconfig.json", // base, including e2e tests
      // Not including tsconfig.prod.ts as it shouldn't have any extra files
    ],
  }
}

Not sure if "ignore" would be useful to me / would allow me using a simple glob then ignoring tsconfig.prod.ts ?

(I know the removal of createDefaultProgram isn't directly related here, but the extra speedup could be worth the less "plug-and-play" install)

[JoshuaKGoldberg]

@Samuel-Therrien-Beslogic have you tried EXPERIMENTAL_useProjectService? A big part of why we haven't added something like nearest in is because we see the project service as satisfying most every use case that nearest would cover, but with easier configuration & faster performance.