Feature request/question: differentiate TS types from "real" imports/exports

Hello and thank you for creating and maintaining this package! ❤️

In TS, I’d like to be able to allow/ban importing/exporting only types (or only non types). AFAIK, that’s not currently possible. (If I’m wrong and it is possible, I’d love to know how and will gladly PR the to make that clearer!)

Context

In a TS code base, I want to allow importing only types (which are stripped during compilation), but ban importing real entities (actual JS: functions, classes and other identifiers which aren’t stripped by the compiler).

The idea is to prevent accidental importing of platform modules into modules which should be in pure JS. For example, in a React Native (Web) app, when authoring a domain object I wish to keep it platform agnostic, free of any RN or browser APIs by ensuring that it only uses in pure JS. In such a file, I’d like to be able to import TS interfaces from different platforms, but prevent it from pulling any actual (platform specific) JS, which could fail to run in an incompatible environment. Example: importing React Native’s AsyncStorage, which would obviously fail during (or after) bundling for web browsers.

Expected Behavior

We should be able to write rules based on whether the entity in question is a type or not.

Current Behavior

We can’t.

Possible Solution

Not sure how I can help, but I’m willing to try 😃

Considered alternatives

Looks like eslint-plugin-import also doesn’t have this capability yet.

[sverweij]

hi @elektronik2k5 I’ve implemented the spike. If you pull in dependency-cruiser@beta you can use it - details on usage in PR #219. All feedback is welcome, so please let me know if it works for your use case (or doesn’t), whether it’s fast enough, the DX is ok etc.

I haven’t had the time to gauge the performance impact - and the feature needs some shaving & sanding, but it works (I’ve ran it against a.o. mscgenjs).

[sverweij]

OK clear. Share your sentiment on the type imports. I just had to ask because if it was just that you needed it’d be easy to implement. And yes - they’re supported by dc already 😃. It’s just they’re currently indistinguishable from other typescript/ es imports. That’ll be easy to correct, though.

dc could indeed do some “dead code” eliminitation, one strategy can be:

1. find the typescript dependencies
2. transpile the typescript to javascript
3. find the javascript dependencies of the resulting transpiled javascript
4. compare the typescript dependencies with the ones in the transpiled javascript. Those in the typescript dependencies but not in the transpiled javascript are ‘dead code’ (either only types or unused real code).

I do have some concerns about performance though - I’ll try to implement a spike for this in the coming days.

B.t.w. a crude version of dead code elimination is already in place - if you switch tsPrecompilationDeps to off dc executes steps 2 and 3 - leaving you with ‘alive’ dependencies only.