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

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