Dependency-cruiser: Typescript - TSConfig path is not taken into account

[Bisdow]

Feature Request

Expected Behavior

I want to create the dependency graph of my project.

My project structure is like this:
src/

• main.ts
• 
  
  • core/
  
  
• - - magicalFile.ts

I am using in the "paths" option the TSConfig.json to create shortcuts for my imports.

relevant parts of tsconfig.json:

{
  ...
    "baseUrl": "src",
    "paths": {
      "@core/*": ["core/*"],
    }
...
}

in my main file "main.ts" i am importing other files with the shortcut.
import { MagicalClass } from '@core/magicalFile'

Now i try to create a dependency table.
dependency-cruiser -v -T html -f dependencyGraph.html ./src/main.ts

I would expect, that dependency-cruiser will take those settings in the tsconfig.json into account and follow the import shortcuts.

Current Behavior

Dependency-cruiser does not take the tsconfig settings into account and try´s to find
@core/magicalFile.ts in the directory @core. Which does not exist.
As a result the dependency graph ends at main.ts and only shows some not resolvable imports.

Possible Solution

It would be nice if, for typescript files, the path option in the tsconfig.json would be taken into account.

Context

For projects wit a certain size, the path-option helps to reduce the length of import statements and to make them more readable.

Your Environment

• Version used: 4.3.2
• Node version: 8
• Operating System and version: Windows 10

Thank you in advance and warm regards

[sverweij]

hi @Bisdow thanks for raising this.

dependency-cruiser is currently indeed not taking tsconfig into account explicitly - mainly because I wasn't aware there were module resolution options in there :grimacing:

I'll look into a solution this week. It will probably involve adding an option to the cli (/ configuration) to supply a tsconfig - similar to what's already in place for webpack configs.

[sverweij]

@Bisdow I've taken this on during the weekend, but noticed something peculiar - the typescript compiler does use the path (and rootDir) properties when figuring out what to compile, but does not seem to write the resolved paths to the generated javascript - when I ran the resulting javascript it still complained it could not resolve @core/magicalFile. What I understand from the typescript documentation is that it assumes the resulting javascript undergoes a processing step as well (e.g. webpack, requirejs, with alias & modules keys etc).

This means I either overlooked a typescript compiler option or need to do some extra processing.

=> what do you use to run/ package the resulting typescript? Or did I overlook a typescript compiler option?

(I have a version on my local machine that takes a tsconfig and passes it on to the compilation step. I'll make a PR for that in the coming days. But while it is an improvement for dependency-cruiser in general it currently isn't useful for resolving _this_ issue. For that I either need a magical compiler option or I need to do some juggling to pass tsconfig options to the resolver).

[ajafff]

TypeScript doesn't rewrite any paths. So this is expected behavior as you already noted.

You don't actually need to do a full compilation. You could either look into https://github.com/dividab/tsconfig-paths or write a small function based on a TypeScript API:

const resolvedPath = ts.resolveModuleName(importPath, containingFile, compilerOptions, ts.sys);

[sverweij]

Thanks @ajafff that's very helpful! I was afraid I was going to need to rewrite the tsconfig path and rootDir to the enhanced-resolve equivalents. Using ts.resolveModuleName looks a lot more elegant.

[sverweij]

Hey @Bisdow - I have a version up that should solve this issue (see PR #57 above for details & a sample). It's on npm as [email protected]. Use in your sample would be:

depcruise -v --ts-config tsconfig.json -T html -f dependencyGraph.html ./src/main.ts

The documentation needs an update to say it now _does_ do the resolve stuff, but you can already give it a spin. I'd love to hear your feedback!

[sverweij]

Version 4.4.0, which contains the merged PR's now is on npm. I assume this closes the issue - let me know if you think otherwise.

[Bisdow]

Works like a charm.