3

I have an Angular workspace (v10.0.2) containing a library and an app (for testing the library).

Inside my projects/libname/src/lib/tsconfig.lib.json I have some paths:

"baseUrl": "./src",
"paths": {
  "@lib/*": ["lib/*"]
}

And I use it like this:

import { DateUtils } from '@lib/utils/date.utils';

I get this warning:

WARNING: No name was provided for external module '@lib/utils/date.utils' in output.globals – guessing 'date_utils'

AFAIK, this means the tsconfig paths aren't replaced so ng-packagr is considering it as an external module. When I looked into the dist folder I saw '@lib/utils/date.utils' still presents and is not replaced with the relative path. If I ignore the warning, when I serve the test app, it gives this error:

Cannot find module '@lib/utils/date' or its corresponding type declarations.

I've searched a lot and read lots of issues snd SO questions, found no solutions.

Vahid
  • 6,639
  • 5
  • 37
  • 61
  • 1
    Sadly it looks like this is not supported by ng-packagr. Pretty tragic because this is such a big feature to not include. Here's a link to a thread where one of the devs doesn't support it. https://github.com/ng-packagr/ng-packagr/issues/519#issuecomment-461487097 – KhalilRavanna Jun 03 '21 at 20:45

1 Answers1

1

The only solution I found is to choose a prefix so that your paths will be exactly the same when the package is installed in node_modules

For example, if your package name is xyz, you tsconfig will be:

"paths": {
  "xyz/*": ["lib/*"]
}

I highly recommend using sub-entries as it not only solved this issue, but also it'll support tree shaking. This article will help

Vahid
  • 6,639
  • 5
  • 37
  • 61