can't consume generated lib when using configured ts paths for imports

[admir86]

Bug Report or Feature Request (mark with an x)

- [x] bug report -> please search issues before submitting
- [ ] feature request

Area

- [x] devkit (not sure)
- [ ] schematics

Versions

node: v8.11.1
npm: 6.1.0
Angular CLI: 6.1.0-rc.0
OS: Win10

Repro steps

• create new ng project with an ng library
• create some components -> see sample demo-lib-app
• use BarService in FooComponent
• import BarService in FooComponent by using the namespace @dl/l (defined in paths area in tsconfig) "@dl/l/*": ["projects/demo-lib/src/*"] -> see sample demo-lib-app
• build and publish the library (I used verdaccio to publish and consume my library)

consume library

• create new project that consumes the new library -> see sample demo-lib-consumer
• install demo-lib-app
• use BarService in a consumer component
• try to build it -> ERROR in ./node_modules/@dl/l/fesm5/dl-l.js...

The log given by the failure

ERROR in ./node_modules/@dl/l/fesm5/dl-l.js
Module not found: Error: Can't resolve '@dl/l/lib/deep/bar/bar.service' in 'C:\Source\Repos\demo-lib-consumer\node_modules\@dl\l\fesm5'

Desired functionality

it should be possible to make imports using the defined paths in tsconfig.
consuming lib in the demo-lib-app test project via "demo-lib/*": ["dist/demo-lib/*"] works fine. but not if the lib is installed in a different project.

Mention any other details that might be useful

[alan-agius4]

This is actually coming from typescript and is by design.

The compiler does not rewrite module names. module names are considered resource identifiers, and are mapped to the output as they appear in the source. The module names you write are not going to change in the output. the "paths" and "baseURL" are there to tell the compiler where they are going to be at runtime.

Check the comment here microsoft/TypeScript#9910 (comment) and microsoft/TypeScript#10866

Seeing this, I would highly discourage using path mapping inside a library and it will make the consumption of the library rather tedious .

[admir86]

Hi @alan-agius4 thx for your feedback.
I haven't expected that the compiler rewrite the names. I thought the name (in my case @dl/l/lib/deep/bar) should be known internally in the module.
I think I expected somthing like an secondary entry point, (I have just read about it). But probably I confuse something.

for summary:
imports in the lib should be done with relative paths, unless I have a secondary entry point for a sub module. right?

[alan-agius4]

Yes correct. On how to implement and use secondary entry points check https://github.com/dherges/ng-packagr/blob/master/docs/secondary-entrypoints.md

…

On Wed, 27 Jun 2018 at 10:26, admir86 ***@***.***> wrote: Hi @alan-agius4 <https://github.com/alan-agius4> thx for your feedback. I haven't expected that the compiler rewrite the names. I thought the name (in my case @dl/l/lib/deep/bar) should be known internally in the module. I think I expected somthing like an secondary entry point, (I have just read about it). But probably I confuse something. for summary: imports in the lib should be done with relative paths, unless I have a secondary entry point for a sub module. right? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#11375 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AQv-WkwQuv1RE0RiBGHcPCkNveFKDOQ0ks5uA0GygaJpZM4U30MY> .

[filipesilva]

Closing as answered by @alan-agius4, thanks!

[angular-automatic-lock-bot]

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

Read more about our automatic conversation locking policy.

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