Quoting the earlier points:
Marco Kaufmann: In my opinion, even when types are erased at runtime, the source code remains the source of truth for developers; the level at which they understand and reason about the software. And so they need to understand the cycle which is a part of it.
Matt Leathes: I would suggest that, for TypeScript types, this issue should not be flagged as ‘high severity’ given that it cannot lead to run-time errors.
I think these two perspectives highlight exactly the core issue: there are two completely different kinds of cycles being grouped together under the same rule.
import { RootState, AppDispatch } from "./store"; // Not Okay, real runtime dependency
import { type RootState, AppDispatch } from "./store"; // Not Okay, real runtime dependency, because only `RootState` is erased
import type { RootState, AppDispatch } from "./store"; // Okay, no real runtime dependency
So while I fully understand Marco’s point about developers reasoning over source code, import type simply does not participate in the same category of architectural dependency that the rule is meant to detect. That’s why Matt’s observation is accurate: treating type-only cycles as high severity doesn’t reflect any actual runtime or structural risk and ends up penalizing a safe and idiomatic TypeScript pattern.