Typescript auto-import uses relative path instead of package in Angular monorepo

I have a fairly basic setup of an angular workspace including two libraries, @scope/lib1 and @scope/lib2. lib2 imports types from lib1.

See this minimal example project for reproducing the problem: https://github.com/PapaNappa/webstorm-monorepo-import/tree/86c89

This monorepo setup makes use of the paths feature/setting from tsconfig.json in the root folder. There, lib1 is referenced from the dist folder. Webstorm seems to recognise this path setting well. Once I build lib1 (npm run build:lib1), the import

import { Lib1Module } from '@scope/lib1';

in lib2.module.ts gets recognised. Features like going to the definition also work very well.

However, auto-imports use relative paths in the import rather than the package names. For an example, see the file lib2.service.ts. It references Lib1Service, but the import is not yet part of the file. Activating auto-import on the use of Lib1Service (Alt+Enter) insert the import

import { Lib1Service } from '../../../lib1/src/lib/lib1.service';

instead of the expected

import { Lib1Service } from '@scope/lib1';

The option 'Use paths relative to tsconfig.json' is disabled.

Is my setup flawed, or is this a bug in WebStorm and should I open an issue?


WebStorm 2018.2.5
Build #WS-182.4892.25, built on October 18, 2018

JRE: 1.8.0_152-release-1248-b19 amd64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Windows 10 10.0

dist is auto-excluded due to https://youtrack.jetbrains.com/issue/WEB-30918 for better performance... And auto-import doesn't consider excluded folders:(

You can mark it as "not excluded": from the folder right-click menu, choose Mark directory as/Not Excluded. This should help:



Thanks for your reply!

The only two main problems with this work-around are:

  • The local file still gets suggested, even as first option. This is error-prone and other developers might choose the wrong import.
  • Which folder is excluded is not a configuration option that gets committed to version control (and I do not want to add the .idea folder to version control).

Can the current behaviour be changed then? I think the monorepo use-case is very valid.

In my opinion, WebStorm should include folders that are specifically referenced in the paths setting of the tsconfig.json. And ideally, the relative path should not get the top priority in the suggestion pop-up (or be excluded altogether). Of course, if I am editing files inside the same package (e.g. import Lib1Service in Lib1Module), then I need to import using relative paths.

May be a bit messy to sort out all the special cases, but I still see the use-case.


A monorepo setup does not seem to be trivial, or WebStorm's support for these use-cases is still limited.

I have removed the exclusion of the dist folder and could successfully import e.g. Lib1Service in lib2.

While WebStorms finds the original declaration of, e.g., Lib1Service in its original source file within lib1/src/lib/lib1.service.ts, the 'Find usages' (Alt+F7) function does not find the usage in Lib2Service when searching from the source of Lib1Service. For the same reason, refactoring does not catch all usages.

So there still seems a long way to go…


Ok, I think I finally found a setup that seems to work. Sorry for the noise, but I will share it in case someone else stumbles upon this.

The solution is to deviate from Angular monorepo setup and refer to the source folders of the library in the paths settings of the tsconfig.json. This way, WebStorm sees the actual source files, and feature like 'Find usages' work well.

The only thing that is left is to add an index.ts parallel to the src/ folder, so Typescript uses this index file (see https://www.typescriptlang.org/docs/handbook/module-resolution.htm). You could also add a "types" field to each library's package.json, but this would mess up the resulting package.json within the dist/ folders.

See my changes on the example repo above.


Thanks. My last solution is also not really working, as this breaks building `ng build lib2`.

I use nx for an application about 150 libraries
the reason for switching to the webstorm (from VScode) was problems with imports and rename, WS is doing better
my current import configuration is