The stylistic config is, well, stylistic. The opinions are what the majority of TS codebases would agree on based on readability, conciseness, and consistency. Now there would always be TS options that make you write code in a different style, and ID often enforces a style that's foreign to non-ID codebases. I don't think we should change the stylistic config to accommodate ID; rather, we could make a config that turns off rules that conflict with ID (for example, in the current world, ID is basically the same as consistent-generic-constructor: ["error", "type-annotation"], so you gain nothing by enabling this ESLint rule).

However, I'm coming over from microsoft/TypeScript#60010, and I think if microsoft/TypeScript#60010 gets accepted, this issue may be completed obsoleted.

That makes sense to me. I think the thrust of my issue is that ID users should have some way to turn on "stylistic" linting without needing to make the individual rule decisions themselves. There are multiple ways to provide that, but having a "stylistic for ID projects" config seems like a perfectly cromulent way to achieve that (as would microsoft/TypeScript#60010, although I'm less clear how feasible that would be to land)

Minor nit: The ID option currently requires type annotations only for exported declarations, so it's a still a style call how to handle local declarations and non-exported module-level declarations.

As awesome and beneficial and exciting as isolatedDeclarations is, a very small percentage of TypeScript projects use it today. It's primarily targeted to large monorepos & such to help with build performance. Their constraints are quite a bit more severe than what most, smaller TypeScript projects go with.

Broadly lessening the usefulness of consistent-generic-constructors in the stylistic config to handle those ID repos would be IMO a net negative. It's a legitimately useful stylistic rule that a lot of folks find benefit from.

However, lint rules do have the ability to read compiler options. I think we can consider it a bug that consistent-generic-constructors produces a report->fix that causes a TypeScript report when ID is enabled.

Proposal (cc @typescript-eslint/triage-team): how about we retarget this issue & marking as accepting PRs to make the rule respect compilerOptions.isolatedDeclarations?

I'm personally at a -1

At best I think we could offer a config to layer on top to disable any rules that conflict with it.

But I would probably say "this requirement applies to less than 10% of configs so it's not worth us building a config to make it easier".

Proposal (cc @typescript-eslint/triage-team): how about we retarget this issue & marking as accepting PRs to make the rule respect compilerOptions.isolatedDeclarations?

What does this look like concretely? Issue an error with incompatible options, like, eg, prefer-nullish-coalescing without strictNullChecks? Or something else?

I was thinking that consistent-generic-constructors should avoid emitting the report about switching generic type arguments when ID is enabled.

@JoshuaKGoldberg

Should ID users just use the 'type-annotation' option, though, rather than the 'constructor' option? Would the 'constructor' option with ID ever report under this proposal?

My 2c is that ID users are rare enough that we shouldn't look to support it aside from making it possible for rules to be used with it when it makes sense.
Some rules are going to conflict with it irreconcilably (eg no-inferrable-types) and some will complement it (eg explicit-module-boundary-types).

We should just make sure that rules that could work with it have the option to do so.

But I don't think we should change the config around it.

Should ID users just use the 'type-annotation' option, though, rather than the 'constructor' option? Would the 'constructor' option with ID ever report under this proposal?

ID is only relevant for exported stuff. Anything local is fine.

export const checked = new Set<string>();

export async function main() {
  const ignored = new Set<string>();
}

We should just make sure that rules that could work with it have the option to do so.

Sounds like we're generally 👍 on this - so from my interpretation, the only next step would be to make consistent-generic-constructors and no-inferrable-types ignore top-level exported stuff when ID is on. Right?

Should ID users just use the 'type-annotation' option, though, rather than the 'constructor' option? Would the 'constructor' option with ID ever report under this proposal?

ID is only relevant for exported stuff. Anything local is fine.

Ah! gotcha, that was the missing part for me. Thanks!

We should just make sure that rules that could work with it have the option to do so.

Sounds like we're generally 👍 on this - so from my interpretation, the only next step would be to make consistent-generic-constructors and no-inferrable-types ignore top-level exported stuff when ID is on. Right?

👍 from me

the only next step would be to make consistent-generic-constructors and no-inferrable-types ignore top-level exported stuff when ID is on. Right?

To determine if ID is on you need type-aware linting so we can get the tsconfig. But both of these rules are not type-aware.

Which would mean we need to add a parser option which the user can manually set or we prefill if type-aware linting is on (just like the emitDecoratorMetadata setup).

Seems like a lot of effort for what is right now a pretty niche usecase, TBH.

Is it more complex than #10499?

I think it's fair to assume ID is going to slowly get more popular over time. Especially given tools like oxbuild and unplugin-isolated-decl getting more popular that generate .d.ts files without tsc. jsr also requires "fast" types, which is explicitly pretty close to isolatedDeclarations.

tl;dr: I'm pretty solidly +1 on taking this cost.

It looks like we have consensus on not changing the stylistic config itself to support isolatedDeclarations (ID). Multiple of us are leaning towards instead having individual rules understand ID and not produce conflicting reports. So I'm going to go ahead and close this issue out in favor of splitting out:

• Bug: [consistent-generic-constructors] Don't conflict with isolatedDeclarations if enabled #10571
• Enhancement(parser): Add isolatedDeclarations as compiler option #10572

Thanks all!