incorrect paths for import statement is generated

[musou1500]

Type of Issue

[x] Bug Report
[ ] Feature Request

Description

incorrect paths for import statement can be generated when a project has multiple library workspaces.

I think the following issue is similar to this issue.
#1109

How To Reproduce

I created a repository for reproduce this bug.

1. git clone https://github.com/musou1500/test-angular-workspace
2. ng build lib2 && ng build lib1
3. open dist/lib1/lib/lib1.service.d.ts. then you can see an incorrect path for import on Lib1Service.test method.

    // should be ../../../dist/lib2/lib2
    test(): import("../../../../dist/lib2/lib2").Entity;

Expected Behaviour

the correct path for import statements should be generated.

Version Information

$ node_modules/.bin/ng-packagr --version
ng-packagr:            5.5.1
@angular/compiler:     8.2.7
rollup:                1.21.4
tsickle:               0.36.0
typescript:            3.5.3

[plchampigny]

We had a similar issue yesterday. Was using a sibling library in a library using it's alias name "@somename/some-library" and imports were being transformed to relative paths. This was causing usage issues.

[damienwebdev]

See this as well for builds of https://github.com/graycoreio/daffodil. I was able to work around it by directly referencing the type in the child library. This appears to only happen for inferred types.

[skorunka]

Having the same issue today. Any update on this?

[skorunka]

I can confirm, that this only happens for inferred types. One solution is to explicitly set the variable type. Or do blank imports - you import the type but it is not used(TSC complains).

[CSchulz]

The workaround is to set types explicitly.

I have noticed for us, it only occurs if I am using some tsconfig path aliases instead of node_modules libraries.

We are performing often a build to a build output folder for reusing artifacts without installing them to the local node_modules folder. This issue is kind of weird.

I also noticed if you install the same library to your local node_modules and let the path alias point to it, it works without any issues.

[rodmax]

Above workaround fixed paths inside dist/ folder

But even corrected paths like ../../../dist/* break TS when we publish our modules due to on client app side we have nodist folder at all due to our lib lives in node_modules/my-lib/{my-lib.d.ts,...}

[maximpn]

I have the same issue. Implicit types from another library in the project generates the wrong paths. The path is ../../../dist/lib-name/... but it should be ../../../../dist/lib-name/.... It seems like a simple baseUrl or something like that related problem.

I've noticed the problem is reverse in the original bug report above, it generates ../../../../dist/lib2/lib2 but it should be ../../../dist/lib2/lib2.

[sommcz]

same problem here, but solved with ng-package.json "dest" configuration.

i've just added another ../ (move my dist dir above library tsconfig) and inferred dynamic imported type path is correct.

"dest": "../../dist/

[Greegko]

Old issue but still had this problem today. For me the preserveSymlinks to true in tsconfig helped.

[lukasarc]

It also occurred with us - when we were using inferred return type. But problem was not in the return type directly, but in optional generic parameter with default type and this default type was the one that also got imported incorrectly (even though the import could have been avoided).

The proposed workarround by @CSchulz did work:

The workaround is to set types explicitly.

[alan-agius4]

Thanks for reporting this issue. Luckily, it has already been fixed in one of the recent releases. Please update to the most recent version to resolve the problem.

If the problem persists in your application after upgrading, please open a new issue, provide a simple repository reproducing the problem, and describe the difference between the expected and current behavior. You can use ng new repro-app to create a new project where you reproduce the problem.

[github-actions]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

_{This action has been performed automatically by a bot.}