Resolving "import type" statements about skott HOT 3 CLOSED

Hello @kevin-st

This left me wondering: does Skott do the right thing with these import statements? I guess the answer is no.

From what you described, it seems that skott is doing the right thing which is using the current TypeScript source code to draw dependencies, and not trying to guess what would happen after transpiling/bundling files.

While I was testing I also created a cyclic dependency on purpose and skott recognized this, but I guess this should be seen as a false positive since the import statements might be removed after compilation depending on the statement.

As it is stated in the documentation, tracking cyclic dependencies is not only useful to avoid runtime issues but also helps for design purposes and to reveal code smells. If you want to only track dependencies that will be there at runtime, you can use skott --no-trackTypeOnlyDependencies which will have for effect to completely discard import type { A } and import { type A } dependencies from the graph.

So my question is: is Skott behaving the way it should or should we catch (at least) these import type statements (if possible)?

skott by default will track the most information possible including type-level information, and I personally find that to be useful, not for runtime purposes, but for design purposes where cyclic dependencies might reveal design smells (this is why this is enabled by default). Sometimes TypeScript might go crazy on type resolution with cyclic dependencies and the compiler might produce errors, so better to avoid them when possible.

Nonetheless it's up to you and you are free to consider them important or not :) I would suggest you to have two different CLI config if the cycles related to types are too noisy, so that you can focus on the ones that will likely be causing runtime issues.

from skott.

Hi @antoine-coulon

I guess it can be interesting to track everything for a project which you're starting up, but since this project was already being worked on for quite some time and given the fact that it's also quite large, tracking everything lead to an enormous amount of circular dependencies, which made it quite hard to find the culprit.

That being said, using the --no-trackTypeOnlyDependencies flag helped to focus on those relations which only exist at runtime and I've managed to bring it down from more than 30 to only 3 circular dependencies, fixing the one relationship which was causing the application to crash. Those last 3 are kind of difficult and maybe even impossible to fix for us, since we are working on an application which is based on a database which is out of our control.

For example: in the database we have a table called articles which links to anglzone and if a record in anglzone has divdir set to "A", then we link back to articles.

We are very tightly coupled to that database and we follow those relations in our TypeScript code, so I guess some of these dependencies just can't be fixed as far as I can see it atm.

Anyhow, thanks for the help!

from skott.

@kevin-st glad to know you could isolate what mattered for you. Don't hesitate to open other discussions if you see any improvement that could make your life easier when dealing with dependencies!

I'll also add more documentation around this topic.

from skott.