Repository navigation
TS importModuleSpecifier could work better for lerna monorepos with libs only #36624
Description
TS Template added by Matt Bierner (@mjbvz)
TypeScript Version: 3.8.0
Search Terms
- importModuleSpecifier
- auto import
- mono repo / monorepo
Related issue: #36181 (I thought was something related to TS itself, but maybe is not).
Right now, the typescript.preferences.importModuleSpecifier auto option only uses relative paths for files nearer to the actual file than the basePath configuration file. But this isn't the best approach for a monorepo full with libs.
I only want to have aliases on imports from other lib folders, but I want to keep every import within a lib as relative imports. The problem is, VSCode suggestions sometimes adds the alias to imports within files of the same lib. When I build and publish everything as is, the service using that lib will crash because doesn't understand the alias.
Thank you in advance!
Activity
mjbvz commentedon Jan 21, 2020
Can you provide a small example project that shows what doesn't work today and explain the expected behavior?
vscodebot commentedon Jan 28, 2020
lgraziani2712 commentedon Jan 28, 2020
Sorry for the delay. Here is the repo: https://github.com/lgraziani2712/vscode-88977
Here is a comment in the built file: lgraziani2712/vscode-88977@07e82a9#r37005671
mjbvz commentedon Feb 5, 2020
Moving upstream for feedback from TS team
Ore4444 commentedon Apr 20, 2020
I'm having the same issue.
compilerOptions.baseUrlin my project tsconfig is set to root of monorepo modules.In every module tsconfig, I have:
compilerOptions.outDir = "lib"andcompilerOptions.rootDir = "src"I don't have a
baseUrlin module tsconfigs which is what causes the mismatch of relative imports (i have exactly the same symptoms as #36181).If I add
compilerOptions.baseUrl = "src"to a module tsconfig, it does solve the issue of doing move refactoring, but for some reason tsc fails with lots of TS2307. Now none of mycompilerOptions.pathsare resolved for that module.The difference between baseUrl and no baseUrl can easily be verified by moving a folder or renaming a file with webstorm.
Seems like when
compilerOptions.baseUrlis set in a composite project,compilerOptions.pathsof parent tsconfig stops having a effect.I've had this issue since the beginning of my monorepo 1.5 years ago. Finally this issue gave me a direction. I'd love to give more context if that would help.
More issues I found that might be related: #36235, #35768, #20110
andrewbranch commentedon Aug 7, 2020
Ore Landau (@Ore4444) what you’re describing sounds like a separate issue than the original post here. Are you able to provide an example repo demonstrating your problem?Actually, this sounds like expected behavior.
pathsare resolved relative tobaseUrl, so if you overridebaseUrlin a child tsconfig, that changes how the parentpathsresolve—specifically, in this case, all thosepathswill fail to resolve.Most of what’s described in this issue, including 100% of the problem in Luciano Graziani (@lgraziani2712)’s example repo, is essentially a duplicate of #31869, and would be solved by implementing that proposal. It does leave open the issue of trying to use a common set of
pathsin a base tsconfig, though, because each composite project will be able to resolve itself with its unrootedpathsentry. Example:The intention is probably:
apppackage can reference any lib by its path mapping - ✔️lib-apackage can reference lib-b and lib-c by their path mappings - ✔️lib-apackage cannot reference itself by the"lib-a"path mapping - ❌To accomplish this, even if #31869 is implemented, each project would need its own
pathssetting to avoid the pitfall of being able to reference itself. I hoped this would be solvable already by lettinglib-a/tsconfig.jsonspecify"paths": { "lib-a": [] }, butpathsin a child tsconfig completely overwritespathsin an extended config instead of merging.