Webstorm not resolving module imports using typescript paths Follow
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:
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.
Please sign in to leave a comment.
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?
Actually no, the problem still persists.
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.
could you share a project it can be reproduced with?
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.
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
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.
It's not always obvious, but the order in which you open the files can matter... The language service normally uses the nearest
.tsfile 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,
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.*.jsonfirst file is included in and not the nearest
> 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.*.jsonfirst file is included in and not the nearest
Any plans to fix this behaviour? :)
no, I'm not aware of any... This is a documented behavior of tscompiler
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.
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.
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...
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.
Elena Pogorelova will you answer this last comment? Because I also think this behaviour is definitely a bug.
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.
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:
also, here is the screenshot showing the problem in the component file
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:
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.
I'd suggest restarting the service after tweaking configs - this would probably take less time
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.
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.
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.
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.
same here :( works for me with WebStorm 2020.3.3 or vs code, but not with WebStorm 2021.1
With Typescript files that are not part of a barrel, the IDE will report an error when you use an aliased library:
For example, if I have src/components/attach-files.component.ts with the following import
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.
DOES NOT WORK.
WANT MY MONEY BACK.
any news about that? it's a BUG!!!!!!!!!!!!!!!!
I'm a huge fan and advocate of Webstorm and a paying customer for many years now. However, I encounter this problem A LOT, particularly when refactoring within a monorepo.
- Restarting the TS service doesn't work
- Restarting the machine doesn't work
- Some files don't have a problem with the imports while others do
- It is wasting a lot of my time!
What's especially stupid is that you can delete the existing imports, then use 'Add import statement' and Webstorm will add the import with a path which it apparently doesn't think is valid!
Paul Eustice, I'm not sure if it's possible with your project but this issue pretty much went away when I made sure everything I was importing was exported from an index.ts "barrel" file. Every time I see the import issue, I just export the necessary components from a barrel file and it goes away. Oddly enough, the barrel file doesn't actually have to be included anywhere else, WebStorm just picks it up automatically. I'm guessing it's looking for index.ts files when it builds the internal index.
Thanks Mike. Unfortunately in my case I am using barrel files religiously. In my current case:
I am moving code from an Angular app into libs, within an Nx workspace. My lib is structured as such:
There's obviously a lot more in there than this basic example, but that's how every directory within the lib is set up. The TS path config is:
It was all working OK Friday and Monday, then it just started highlighting tonnes of imports despite TS itself being fine, and nothing changing with regard to the existing lib code, or the TS path config
Paul Eustice Do you have a sample project you could share that reproduces the problem?
FYI: Same problem here. In a large pnpm monorepo, importing base tsconfigs via "extended" does not work. cli tsc works fine.
I managed to solve this by:
This works because the Options field is only used when no typescript config file is found, as stated in docs: