Enhancement: Allow adding test directories and files to allowDefaultProject glob

[jgeurts]

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

typescript-estree

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

I have an eslint config where I'm trying to set up some defaults for all consumers of the config. One of those defaults is to add all test files to the project service:

parserOptions: {
  projectService: {
    allowDefaultProject: ['./tests/**/*.{ts,js,cjs,mjs}'],
    defaultProject: 'tsconfig.json',
  },
  tsconfigRootDir: import.meta.dirname,
},

That configure is causing Parsing error: allowDefaultProject glob './tests/**/*.{ts,js,cjs,mjs}' contains a disallowed '**'. errors.

I understand the risks and would still like to use that glob pattern. Is there a config setting or any other path forward to allow the ** glob pattern in this case? In this case, the glob pattern is constrained to all subdirectories of a single path (./tests), maybe the validate function could be a bit looser in that case and allow it?

Additional Info

No response

[JoshuaKGoldberg]

🤔 interesting. Why doesn't your tsconfig.json include any of your test files? I've never seen such a significant omission before.

[jgeurts]

@JoshuaKGoldberg Mostly to keep those files out of the build - which might be flawed logic. We have a separate tsconfig.tests.json file that included the test files and I suppose in that case, I could allow the consumer to override the default project.

[JoshuaKGoldberg]

I would assume that to be ... well, unusual logic 😄 yes. tsconfig.json tells editors and other consumers of language / project services how to generate type information for all files. Instead of having a separate tsconfig.tests.json, I'd suggest:

• tsconfig.json: including all files you care to have type info for
• tsconfig.build.json: changing settings for what you specifically need to build

In other words, making building the separately-configured-from-the-norm case, not editor intellisense.

[jgeurts]

Makes sense, I appreciate the feedback!

[bradzacher]

Yeah the general workflow is to use tsconfig.json for everything to power the IDE and generic typechecking, and then create separate tsconfigs for each usecase (build, test) to create isolated environments.

Having files uncovered in the IDE and relying solely on the default project is a recipe for confusing experiences and breakages! For example if you update from TS 5.4-5.5 then the default project's default tsconfig settings changed - which could mean you start seeing errors in those files that don't reproduce from the CLI.

[JoshuaKGoldberg]

Closing out as this really isn't a pattern we want to encourage. Thanks for filing!