Issue: Dependency cruiser is unable to correctly resolve aliases defined using "paths" in tsconfig that start with '/' (tsconfig-paths issue)

[surgicaI]

We are currently using ViteJS as our devServer, and the condition to define alias there is that it should start with a forward slash (/). If you want to know why is that the case, checkout this link.
Thus our paths property in tsconfig.json looks like this

"paths": {
  "/@utils/*": ["src/utils/*"]
  "/@services/*": ["src/services/*"],
  "/@contexts/*": ["src/contexts/*"],
  "/@src/*": ["src/*"]
},

Earlier when we were using the aliases without / dependency cruiser was working perfectly fine, eg: defining alias like "@utils/*": ["src/utils/*"], works.

Expected Behavior

Dependency cruiser should be able to resolve the aliases correctly

Current Behavior

It is not able to resolve the aliases correctly. As can be seen from the example shared below to reproduce the issue, it's treating the alias as a separate directory. link

Possible Solution

Not sure.

Steps to Reproduce (for bugs)

Following repo can be used to reproduce the issue
https://github.com/surgicaI/dependency-cruiser-repro

Context

We want to use dependency cruiser to add forbidden dependency tests and due to this bug we are not able to do so.

Your Environment

• Version used:9.8.0
• Node version:14.7.0
• Operating System and version:MacOS Catalina
• Link to your project:N/A

[sverweij]

hi @surgicaI thanks for raising this issue and for preparing the repro-repo.

Aliases in tsconfig do work (and there's several unit tests in place to ensure they keep working). In your specific case the / in front of the alias name throws a spanner in the works. When you remove or replace it with something else in both the source & tsconfig works fine. I suspect a piece of resolver code is deciding a tad too early to declare it an absolute path.

As dependency-cruiser should be able to work even with aliases like that, I'll add a unit test with relevant parts of your tsconfig and work from there to see what exactly is throwing that spanner.

[surgicaI]

Thanks @sverweij for such a quick response

[sverweij]

@surgicaI Found the root cause: dependency-cruiser uses tsconfig-paths-webpack-plugin for handling tsconfig paths. That in its turn uses tsconfig-paths which at the moment doesn't work (yet, I hope) with path names that start with a /. An issue for this already exists in the tsconfig-paths repo: issue 128: "Does not work for path mapping starting with /"). The suggested fix in that issue looks fairly simple, so I wonder why nobody made a pull request yet...

So this needs to be fixed upstream, or dependency-cruiser needs to start looking for alternatives for tsconfig-paths-webpack-plugin.

[slaivyn]

I have the same problem and I am not allowed to change the path structure of the large code base I want to analyse...

@sverweij @surgicaI there is a new PR that would fix this upstream problem: dividab/tsconfig-paths#184

[sverweij]

@slaivyn / @surgicaI - it seems now

• Fix the root path dividab/tsconfig-paths#180 is merged and
• tsconfig-paths-webpack-plugin has upgraded (yesterday) to the latest version of tsconfig-paths (chore: update tsconfig-paths dependency dividab/tsconfig-paths-webpack-plugin#90)

... the upstream bug seems to have been fixed. I've bumped the tsconfig-paths-webpack plugin to latest and shipped it in [email protected], which is on npm as of now.