Webstorm not resolving module imports using typescript paths

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 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

> 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? :)

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...

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.

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:
https://github.com/sandeep-sethia/webstrom_lint_issue.git 

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:

• 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.

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.

    "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.

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

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';

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:

libs/shared/utility/src
  lib/
    services/
      service1.ts
      service2.ts
      index.ts <- export * from './service1.ts'; export * from './service2.ts'
  index.ts <- export * from './lib/services';

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:

"@libs/shared/utility": [
  "libs/shared/utility/src/index.ts"
],

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:

1. Going to Editor | File Types, then, for TypeScript config, remove all file types present in my project (in my case tsconfig.json and tsconfig.app.json). This prevents WebStorm from automatically choosing the config file to use.
2. Now that WebStorm doesn't know which file to use, you can now go to Languages & Frameworks | TypeScript and in the Options field add the --project parameter with the path of the tsconfig.*.json file you would like to use, like so: 

--project C:\path_to_project\src\tsconfig.app.json

This works because the Options field is only used when no typescript config file is found, as stated in docs:

In the Options field, specify the command-line options to be passed to the TypeScript Language Service when the tsconfig.json file is not found.

https://www.jetbrains.com/help/webstorm/typescript-support.html#ws_ts_use_ts_service_checkbox