Enhancement: Disallow parserOptions.project: [] (prefer false and/or null?)

[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

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

Forwarding @fisker's #8136 (comment) here: right now, it seems there are three ways to turn off parserOptions.project in some way:

• false
• null
• []

That last one, [], is something I didn't know anybody was using (thanks @fisker for mentioning!). My interpretation of parserOptions.project set to an array is that providing a project array says explicitly that there is a list of projects. So not providing any projects in that list means you'll never find the types. If there's no difference between that and false/null, then this is an ambiguity we need to at least document.

Proposal: as a breaking change for v7, if we see an empty array, perhaps we should throw an error (à la #6403) asking the user to either put projects in it, use v7's name for EXPERIMENTAL_useProjectService, or set it to false / null?

Additional Info

Adding to the v7 v8 milestone as we should really lock this down while we have the change to make breaking changes if needed.

[Josh-Cena]

I don't think people would consciously write projects: []; however, it is very possible to end up with passing an empty array in cases of:

module.exports = {
  projects: [
    // TODO: bla bla
    // "tsconfig1.json",
    // TODO: bla bla
    // "tsconfig2.json",
  ],
};

module.exports = {
  projects: getProjects().map(...),
};

And in both cases preventing the empty array seems unnecessarily uncharitable.

[fisker]

I think I remember why I use [] now, it doesn't allow false at all,

typescript-eslint/packages/typescript-estree/src/parseSettings/getProjectConfigFiles.ts

Lines 25 to 33 in 958feca

	if (project !== true) {
	if (project == null) {
	return null;
	}
	if (Array.isArray(project)) {
	return project;
	}
	return [project];
	}

I don't like {project: undefined}, because {} is the same(and I'm the author of unicorn/no-useless-undefined rule), but {} can't prevent the parser change default value, I also don't like {project: null}(again.. author of unicorn/no-null rule).. {project: []} is my best choice to exist this function.

[fisker]

And getProjectConfigFiles returns different result for {project: null} and {project: []}...

[bradzacher]

The issue with using [] is that the ESLint merges arrays and objects. null will override or by overridden, but empty objects and empty arrays will be merged and not override.

That's why our disable-type-checked config explicitly uses null.

typescript-eslint/packages/eslint-plugin/src/configs/disable-type-checked.ts

Line 9 in 8450dbe

parserOptions: { project: null, program: null },

It looks like this might be slightly different in flat configs though - arrays override but objects merge.

We should treat an empty array the same as off, regardless.

[Josh-Cena]

So, are we still doing this? To me it sounds like putting an extra patch on something that was very logical in the first place.

[JoshuaKGoldberg]

Yeah I no longer have motivation to push for anything here. The differences make sense and I'm happy with the status quo. Thanks all 😄