TypeScript+Webpack resolving dependencies in symlink folder

Question

I've faced with problem that TypeScript+Webpack doesn't resolve correctly dependencies if they are in symbolic linked folder. I have file structure like this:

- main
-- index.ts
-- package.json
-- webpack.config.js

- shared-lib
-- services
--- session.ts
-- package.json

In main there is a dependency for shared-lib@file:../shared-lib, in result npm would create symbolic link in node_modules for it.

In shared-lib I have dependency for lodash-es, as well as I have it in main, but the thing that there should be only one lodash-es in project, which I want to keep in main, in result when I try to build the project I get something like:

ERROR in [at-loader] ../shared-lib/index.ts:1:24 TS2307: Cannot find module 'lodash-es/capitalize'.

Webpack was complaining about this as well but can be fixed if provide an absolute path to node_modules in resolve.modules. Now looks like the only TypeScript not aware where to look for dependencies. I've looked through TypeScript configuration documentation and cannot find anything helpful, is there any way to give a hint to TypeScript where to look for dependencies, if file located outside of the main folder? I tried to use rootDirs but seems it's not for my case.

Answer 1

Ok, TypeScript has 2 (maybe more, but in my case only 2 has been used) strategies for solving non-relative dependencies, and they both depend on real file path. If npm would copy local dependency then there wouldn't be any issue, but it create symbolic link.

I've found out one workaround which might fixes this issue, but not in the most elegant way. If specified baseUrl as ., then paths can be provided, and exact location for 3rd party dependency can be provided.

Right now my .tsconfig has following lines:

"baseUrl": ".",
"paths": {
  "lodash-es": ["node_modules/lodash-es"]
},

This would force to resolve all lodash-es entries to ./node_modules/lodash-es where dot points to main project root.

Hope that TypeScript would provided possibilities to customize Module Resolution strategies.