depcheck: TypeScript tsconfig.json path-mapping not being used

Cause path alias are widely used.

They shouldn’t be 😃

@stale nice try, see you in 5 months

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.

@PapaStef sure, open a PR.

Would be great to have depcheck handle this for tsconfig, webpack, and any other special we are supporting.

This is a feature that sees a lot of use in larger projects. Whether that’s recommended is ultimately an opinion, but it does solve the problem of long relative paths for imports, which brings value to certain types of projects. At the end of the day, aliased code compiles perfectly and the dependencies are - in fact - not missing. I think most would agree that when running a dependency checker in a TS/Webpack project, aliased imports should not be marked as missing when they are perfectly valid, as this is a fully-supported feature in Webpack.

Thanks for all your work on this project! I know it’s probably a pain to support some of these features and I would be more than happy to work on a PR if you are still open to it 😄

@stale still not a good idea

Please don’t close it Mr. Bot

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.

Hey, thank you for your thorough response! Your points totally make sense for me so don’t worry about it!

Have a nice day =)

Related yes, also see my comment: #544 (comment)

I’m going to need a lot of persuasion to do this

I think this is a necessary ability for typescript based project. Cause path alias are widely used.

I am using a similar config but mine seems to work ok with depcheck. If use path it works if I don’t and only use basUrl it fails depcheck

This fails depcheck:

"compilerOptions": {
    "baseUrl": "./src",
}

import Component from 'components/path/to/file';

This don’t fails depcheck:

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

import Component from '@/components/path/to/file';

Related yes, also see my comment: https://github.com/depcheck/depcheck/issues/544#issuecomment-640455125

I’m going to need a lot of persuasion to do this

Let me give you an alternative argument on why it is an useful feature we would like to see in depcheck.

It might be considered to be a bad practice to use path aliases to make relative imports shorter (I agree with this), but some monorepo toolings like Nx use TS path aliases to refer to local libraries. This makes it possible for Nx to build a dependency graph for integrated monorepo. So in this case it’s not a mere opinionated decision to use path aliases in a repository, but a required feature if one uses the most used monorepo tooling in a TypeScript environment.

Open a PR

Not sure that the size has anything to do with it…

I really don’t like this feature webpack and typescript implement, I mean there are better ways to do this today, like workspaces.

Both of the above comments are opinions. 😉

The fact remains that it’s a big ask and is entirely reasonable to not implement for that reason, even though it would also be nice.