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

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.

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.

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)

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.

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)

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

It's been ~4 months since last comment and there haven't been any new motivators for this. Closing it out as having not had enough community feedback to suggest we should take action.

If anybody sees this and thinks they have a good reason not yet mentioned, please do file a new issue! We'd be happy to take a look.

Thanks for the discussion all!

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.

@JoshuaKGoldberg What about this comment from above? The motivator is the same as mentioned above, but it seemed like this was a viable option. Is that still the case?

That comment would be a nice solution, but we haven't seen enough evidence that the root problem is something we need to solve. projectService is the recommended path going forward and we just haven't seen a lot of interest in this feature request for project: true.

From another direction:

1. This request had ~19 👍s from before projectService was available, which indicates the root issue of "we need better ways to provide type info" is valid
2. Now that projectService is available, we've seen almost no added user requests for this one - nor indication that projectService just isn't enough
3. We've also learned from real world usage why it's often not a good idea to have TSConfigs other than tsconfig.json: https://typescript-eslint.io/troubleshooting/typed-linting#id-like-to-use-tsconfigs-other-than-tsconfigjsons-for-project-service-type-information

...so all together, it's looking like needing a project: true that looks at any TSConfigs other than tsconfig.json is not something we'd want to recommend.

But, hey, if someone can post a strong motivator why we're wrong to close this issue, great! Please do! I'd suggest chatting with us in the typescript-eslint Discord first so we can take a deep look.