TypeScript tsconfig.json path-mapping not being used

Context: https://stackoverflow.com/questions/37372816/what-does-symbol-mean-in-import-component-from-angular-core-statem https://www.typescriptlang.org/docs/handbook/module-resolution.html#path-mapping

Our app has imports like: import { Foo } from "@services/foo"; with the following in tsconfig.json:

{
  "compilerOptions": {
    "baseUrl": ".", // This must be specified if "paths" is.
    "paths": {
      "@service": ["src/app/services/*"] // This mapping is relative to "baseUrl"
    }
  }
}

Then depcheck outputs:

Missing dependencies
* @services/foo: ./src/bar.ts

Expected behavior: depcheck should find and read paths in tsconfig files.

PS: Not sure, but maybe https://github.com/depcheck/depcheck/issues/544 is related.

[rumpl]

Cause path alias are widely used.

They shouldn’t be 😃

[rumpl]

Here’s my take on why I don’t want to implement this in depcheck.

I am not a fan of it. That’s just an opinion granted, but I would like to think my opinion is important for my project.

Path aliases add an unnecessary indirection, I have worked on multiple project that use them and, as a new developer to the project, I found it very hard to know just from looking at the code if an import is a local one or one from a dependency. It’s also hard, for someone new, to know and remember all the path aliases. The tooling around is pretty much non-existent so my IDE is always complaining about unknown dependencies.

I you look at the examples in the typescript documentation you can see that they talk about paths as a tool for some exceptional setups (modules not under baseUrl, generated code, etc). The --ignores flag exists exactly for these exceptional cases. The problem here is that, instead of using lerna/webpack workspaces you use aliases.

Would you accept PR’s?

I’m torn, really torn, you’ll open the PR and then I’m left maintaining something I don’t want to maintain and don’t like… So no.