Issue: Dependency cruiser is unable to correctly resolve aliases defined using "paths" in tsconfig that start with '/' (tsconfig-paths issue)
See original GitHub issueWe 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
Issue Analytics
- State:
- Created 3 years ago
- Reactions:1
- Comments:5 (3 by maintainers)
Top Related StackOverflow Question
@surgicaI Found the root cause: dependency-cruiser uses
tsconfig-paths-webpack-pluginfor handling tsconfig paths. That in its turn usestsconfig-pathswhich 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 / @surgicaI - it seems now
tsconfig-paths-webpack-pluginhas upgraded (yesterday) to the latest version of tsconfig-paths (https://github.com/dividab/tsconfig-paths-webpack-plugin/pull/90)… the upstream bug seems to have been fixed. I’ve bumped the tsconfig-paths-webpack plugin to latest and shipped it in
dependency-cruiser@11.13.1, which is on npm as of now.