Enhancement: [consistent-type-imports] option to only enable for internal dependencies

[kuba-orlik]

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.

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

Link to the rule's documentation

https://typescript-eslint.io/rules/consistent-type-imports/

Description

The largest benefit I see in the consistent-type-imports rule is decreasing the amount of cyclic dependencies in the generated code.

I propose to add a new option to the consistent-type-imports rule that would only enable the checks for internal dependencies (where import path starts with a .).

Fail

import Shape from "./shapes.js"
import Container from "containers"

function create(): Container<Shape> | null{
    return null;
}

Pass

import type Shape from "./shapes.js"
import Container from "containers"

function create(): Container<Shape> | null{
    return null;
}

Additional Info

No response

[bradzacher]

Whats the motivation here? What benefit is there to just using it like this as opposed to just being consistent and treating all imports the same?

I don't see how there's broadly applicable value in being inconsistent and special casing this.

The largest benefit I see in the consistent-type-imports rule is decreasing the amount of cyclic dependencies in the generated code.

I strongly disagree. The benefit is to ensure your imports are properly qualified so that you can leverage non-type-aware transpilers or analysis tools to their fullest.

It allows you to creat self-documenting code that clearly describes the value-domain and type-domain imports.

[kuba-orlik]

Whats the motivation here? What benefit is there to just using it like this as opposed to just being consistent and treating all imports the same?

If the rule is enforced for all imports, then we get linter warnings on lines like

import {a,b,c,d} from "some-package";

If only some of those imports are for the type, and others for value, then we have to change it to

import type {b,d} from "some-package";
import {a,c} from "some-package";

That's extra work for our team that gives benefits less important (to us!) than what was the intention behind enabling this rule: decreasing cyclic dependencies across our codebase

[bradzacher]

That's extra work for our team

But the rule has an autofixer for all cases - so you just run --fix and it fixes everything. So it's the same amount of work if it reports on one or one thousand imports.

---

The rule isn't intended to do anything around cyclic dependencies. If you're looking to reduce cyclic deps there are separate rules for that.

---

I don't see any broad applicability here and the motivation does not align with the intent of the rule. Thus I am going to reject this.