Dependency cycle detected import/no-cycle

Hello,

After an update from ‘2.22.1’ to ‘2.23.0’ I have this error

Dependency cycle detected import/no-cycle

I’m trying to import a TypeScript Type like this:

./Bar.ts

import useBar from './useBar';

export type Bar = {
  msg: string
}

---

./useBar.ts

import type { Bar } from './Bar';

Previously import type even if it was cycled import worked.

[raycharius]

An option would be great – I would love to have this rule included. And I have a feeling that this has broken eslint for a lot of people ❤️

As for import type creating runtime issues, it won’t, even with enums and classes, though using import with an enum will. I’ve created a small test repo that demonstrates this here.

In the documentation for import type, they say:

import type only imports declarations to be used for type annotations and declarations. It always gets fully erased, so there’s no remnant of it at runtime. Similarly, export type only provides an export that can be used for type contexts, and is also erased from TypeScript’s output.

However, there is a very poorly worded section:

It’s important to note that classes have a value at runtime and a type at design-time, and the use is context-sensitive. When using import type to import a class, you can’t do things like extend from it.

It can lead to the impression that import type will have a value at runtime, but looking at the example below, it’s about the inability to extend the class as you would with an interface using import type.

If you’re good with a flag, I’m happy to take a look and send over a pull request

[raycharius]

Sorry, @ljharb, but this is wrong. The purpose of this rule is to avoid possible issues at runtime with circular dependencies. Using import type will never lead to that. Moreover, I disagree about this always being bad architecture when it comes to importing types. There are plenty of cases when this is more than appropriate.

At the very least, it should be configurable to exclude import type.

The makers of Madge know and understand that.

In any case, this has rendered this check useless for me because of this, which is actually really unfortunate. So, turning this rule off and integrating Madge into CI flow.