Webstorm not resolving module imports using typescript paths

Hello there! I am using Webstorm 2019.3.4

I found it very problematic to configure "paths" option so that IDE does not show me error hints (tsc compiler works as expected). The story is the following, I have two tsconfig files one extending the other:

src/server/tsconfig.prod.json:

src/server/tsconfig.json:

 

In my case, tsonfig.json extends tsconfig.prod.json, so I believe every rule from tsconfig.prod.json should automatically be applied to code analysing via default tsconfig.json file. But I encounter the following problem when trying to import files from src/shared directory:

 

I tried literally everything: adding include: ["**/*"] to both tsconfig and tsconfig.prod and much more, but nothing seems to work. What am I doing wrong here? The most frustrating thing is that compiling my project with proper config leads to no errors at all.

Could someone please help with this? I am totally confused.

22 comments
Comment actions Permalink

Please try adding tsconfig.prod.json to the list of patterns registered for TypeScript Config file type in Settings | Editor | File Types and restart the IDE - does it help?

0
Comment actions Permalink

Actually no, the problem still persists.

0
Comment actions Permalink

Just checked the project in VisualStudio, it shows the same error, so this is probably not a bug of WebStorm, I just can't get what is wrong in my scenario.

0
Comment actions Permalink

could you share a project it can be reproduced with?

0
Comment actions Permalink

No, basically I cant reproduce it with small repositories. I tried a lot, but it seems to work correctly for small stubs. I am desperate, I really do not want to switch to VS code because I love your IDE. However, now things got even worse. It seems like WebStorm stopped to recognise nested tsconfigs, look below.

Any file in the project produces errors concerning missing --jsx in tsconfig and cannot resolve imports. Example:

And here how this src/client/tsconfig looks like:

 

As you can see it has --jsx flag and --baseUrl, so everything should be cool, but I have a lot of errors. Can I at least disable typescript checks for the whole IDE? Note that if I put these options into root tsconfig, everything is becoming cool. Webstorm acts as if no src/client/tsconfig exists and I simply cannot fight with it. Please, please, help me.

 

 

0
Comment actions Permalink

can't reproduce... Could you check if the order in which you import files matters? Close all files except for this .tsx, close project, then re-open it - can you still see the errors?

To disable typescript checks, you have to turn tsserver off in Settings | Languages & Frameworks | TypeScript by disabling Typescript Language Service option

1
Comment actions Permalink

Elena, wow! Thank you for such a quick help! Indeed, that helped a lot, now the project does not show any errors, as expected. I tried literally everything: reinstall app, update to 2020.1, update macOS to Catalina, invalidate cache and restart. But during all these operations there were the same files open.

Now I closed all of them, restarted IDE and everything works.

Could you tell why this happened? From my experience with WebStorm I could say that this happens quite often, usually I was able to edit configs, but this time I literally got stuck.

0
Comment actions Permalink

It's not always obvious, but the order in which you open the files can matter... The language service normally uses the nearest tsconfig.*.json current .ts file is included in, traversing the folders hierarchy from current folder up to the IDE project root.

But, as it's written in https://www.typescriptlang.org/docs/handbook/tsconfig-json.html,

Any files that are referenced by files included via the "files" or "include" properties are 
also included
. Similarly, if a file "B.ts" is referenced by another file "A.ts", then "B.ts"
cannot be excluded
unless the referencing file "A.ts" is also specified in the "exclude" list.

 That's why if you first open a file that is referencing your tsx via the imports chain, this tsx will be processed using the tsconfig.*.json  first file is included in and not the nearest tsconfig.json

1
Comment actions Permalink

> That's why if you first open a file that is referencing your tsx via the imports chain, this tsx will be processed using the tsconfig.*.json  first file is included in and not the nearest tsconfig.json

Any plans to fix this behaviour? :)

1
Comment actions Permalink

no, I'm not aware of any... This is a documented behavior of tscompiler

0
Comment actions Permalink

Well, but it causes really big troubles when IDE literally shows you that all your project is full of errors.

Behaviour is unstable and those errors may come at any moment if the structure of tsconfigs in the project is complicated.

1
Comment actions Permalink

By the way I did not find any place with warnings about it, if I didn't open this topic I would probably switch to VScode. It seems for me this is a strange policy.

1
Comment actions Permalink

This has been driving me crazy for three whole days now.

I recently split an Angular application into two separate applications within the same project and started seeing these errors about paths defined in tsconfig.json not being found, even though the project compiles and serves just fine.

I was convinced that I messed up the config when I separated the applications, and I've been trying every possible tweak to the main tsconfig.json and the two individual applications' tsconfig.app.json files, I've been invalidating the cache and restarting the IDE, I tried it in just WebStorm rather than IntelliJ (even though they're basically the same thing).  I even created a new project with two simple, brand new Angular applications in it and saw exactly the same problem!

I've been searching for the answer to this and I've been reading and re-reading the official TypeScript documentation about module resolution and config files, and running tsc with --showConfig and --traceResolution and nothing stood out.

I luckily just finally stumbled upon this thread and read this comment, closed down all of my open files and opened the single file that had the import error and then it went away:

> It's not always obvious, but the order in which you open the files can matter...

Madness.

</rant>

 

Anyone who opens a file expects path resolution to happen based on that file's nearest tsconfig, not based on the tsconfig nearest to the first file that you opened.

I opened my project in VS Code and the problem does not occur there, so I don't think it's fair to say that this is expected behaviour and is not a bug in IntelliJ/WebStorm.

This is really terrible behaviour.  Please raise this as a bug and fix it.

1
Comment actions Permalink

Elena Pogorelova will you answer this last comment? Because I also think this behaviour is definitely a bug. 

0
Comment actions Permalink

Hi, I had similar issues. All import paths without .ts at the end of the import had red underline, but it would compile. When I added .ts, red line disappeared but it would not compile. The biggest issue was it did not show me the actual errors in my code. I had to open Visual Studio Code to fix those. 

I played with Deno before in a different project.  And Deno expects .ts to be at the end of the import. So I disabled Webstorm Deno plugin and the issue went away. For the devs, I know for sure I do not use and I did not enable Deno plugin for that particular project.

I hope this helps someone.

0
Comment actions Permalink

I have tried everything suggested in this post but this does not solve the issue. my scenario is exactly same as mentioned by Goroddt. I have a main project with lots of small libraries with each having its own tsconfig.json file and all these file are extending the "tsconfig.base.json" file in the main project.

 

Is there anything else I can try to solve this?

if it helps, I have the working logic at this github repo:
https://github.com/sandeep-sethia/webstrom_lint_issue.git 

 

also, here is the screenshot showing the problem in the component file


0
Comment actions Permalink

Some tips for those who are struggling with TypeScript language Service in Webstorm and multiple tsconfig files extending one another - and WS+TS inspections seemingly ignoring your configuration changes in tsconfig.*.json.

I had a similar issue where Webstorm TS checker would not pick up on config changes.
And the reason is I was not aware that it takes at least 30-40 seconds after config change for the Typescript service file inspections to update and take effect! My project is not small, so that definitely adds to the delay and TS checks take at least 30-40 seconds in my project.

So for example, my tsconfig.*.json files setup:

  • tsconfig.json: main TS config for the project.
  • tsconfig.eslint.json: this file is loaded by ESLint with TS integration via .eslintrc.js - and this file extends the main tsconfig.json file:

    In this file I also have extra "include" paths for test files - which are not in the main tsconfig.json as I don't want *.test.js files to get compiled into main bundle etc.

I am running Webstorm on Windows 10 with WSL - this is what my WS Typescript configuration looks like:

If I was to update tsconfig.eslint.json file, for example changing compilerOptions.skipLibCheck = false, Webstorm would pick up the change after a long-ish delay - as long tsc would take to do all the type checks in your project.

So be aware that after tweaking your tsconfig.*.json file - the file inspection updates in Webstorm take effect only after some time and NOT immediately. It may take as much as the standalone npx tsc --noEmit -p ./tsconfig.eslint.json command would take to finish - and maybe that's what TS service is running behind the scenes anyway.


0
Comment actions Permalink

I'd suggest restarting the service after tweaking configs - this would probably take less time

0
Comment actions Permalink

From what I have checked, restarting the Typescript service takes about the same time. This is probably because `tsc` type checks need to run from scratch in either case because of config change. 

0
Comment actions Permalink

I have an Angular 9 project that I started around Angular 7 and I believe I have had this problem persistently through all the upgrades and I have found no solution.  None of the solutions presented seem to work but I do believe I'm representative of some of the other Angular posts about this. 

I have an Angular workspace with 4 projects, 2 Application projects and 2 Library projects (see tree below). When I load the workspace in IDEA, I'm only able to have Typescript module aliases work in one of the Application projects.  The definitions are identical in the `tsconfig.json` files located in the Application projects.

    "paths": {
"@lib-app/*": [
"projects/lib-app/src/lib/*"
],
"@lib-auth/*": [
"projects/lib-auth/src/lib/*"
]
}

With this setup, I can use `@lib-auth` or `@lib-app` in the `app-web` project but not in the `app-admin`.  I just end up using the extremely long import path that IDEA suggests but it would be wonderful if I could use the aliases instead.  Are there any suggestions for how I should tackle fixing this problem?

Here's a tree of my Angular workspace.

├── angular.json
├── package.json
├── package-lock.json
├── projects
│   ├── lib-auth
│   │   ├── src...
│   │   ├── tsconfig.lib.json
│   │   ├── tsconfig.lib.prod.json
│   │   ├── tsconfig.spec.json
│   │   └── tslint.json
│   ├── lib-app
│   │   ├── src...
│   │   ├── tsconfig.lib.json
│   │   ├── tsconfig.lib.prod.json
│   │   ├── tsconfig.spec.json
│   │   └── tslint.json
│   ├── app-admin
│   │   ├── src..
│   │   ├── tsconfig.json
│   │   ├── tsconfig.spec.json
│   │   └── tslint.json
│   └── app-web
│   ├── src...
│   ├── tsconfig.json
│   ├── tsconfig.spec.json
│   └── tslint.json
├── tsconfig.json
└── tslint.json

Update

I get "Project Errors" listed and they'll all be something to do with my alias import usage.  The strange thing is that if I work in a file (any file) those errors will go away or be greatly reduced.  As I continue to work they will pretty much always completely disappear.  They will also always come back, particularly when I re-open my project.

0
Comment actions Permalink

I have tried everything suggested in this post but this does not solve the issue. my scenario is exactly same as mentioned by Goroddt. I have a main project with lots of small libraries with each having its own tsconfig.json file and all these file are extending the "tsconfig.base.json" file in the main project.

 

same here :( works for me with WebStorm 2020.3.3 or vs code, but not with WebStorm 2021.1

0
Comment actions Permalink

With Typescript files that are not part of a barrel, the IDE will report an error when you use an aliased library:

"TS2307: Cannot find module '@lib-app/data/service' or its corresponding type declarations"

For example, if I have src/components/attach-files.component.ts with the following import

import {AppService} from '@lib-app/data/service';

I will get the TS2307 error and the import statement will be shown with a red underline.  As soon as I add `attach-files.component.ts` to a barrel file, like the following, the error goes away.

export * from './attach-files.component';

 

0

Please sign in to leave a comment.