ng-packagr: Confusing error "WARNING: No name was provided for external module 'xxx' in output.globals – guessing 'xxx'" for absolute imports

@LastDragon-ru Path Mappings are supported by ng-packagr. In order to understand the underlying issue, some context is needed:

• By doing this, importing from these mapped paths will be treated as externals (like if you would import sth. from node_modules)
• This means btw, that these imports won’t be included in your angular library
• The term “name” form the warning here refers to UMD ID's. Beside ESM and FESM Formats, APF specifies also UMD bundles to be included.
• The UMD ID of a package will be used to assign a property for globalThis (window for browsers), where the name of the property will be the UMD ID and the value are all the public exports of your library (e.g. here: window['xxx'])
• Now when another library imports yours, then your UMD ID can be provided, so the another library knows how the property is called for globalThis
• The issue here is, that ng-packagr cannot know under which UMD ID the path mapped imports will be attached to. Said that, it will ‘guess’ a ‘name’ and thankfully warns the user about that.

Recap

• If you are going to publish your library, consumer will have to import also the path mapped stuff, which are not bundled in your library
• To define the UMD ID of your library, set the umdId property in your ng-packagr config.
• To provide UMD ID’s from other libraries, you need to set key/value pairs in a umdModuleIds object in your ng-packagr config., wheree key is the import identifier and the value the UMD ID of that library.
• If you are not going to use UMD bundles (default angular app does not), then you don’t need to bother with all this.

To get away from the warning, just provide the same identifier you have used in the path mappings in your ng-packagr config

Real world example project (which I already linked in my previous reply):

• The path mappings are defined here for a shared library, which is used by other libraries / apps
• The shared library itself defines an UMD ID here
• The other libraries are provided with the UMD ID of shared here

This is also the proof, that path mappings are supported correctly 😉

cheers flash ⚡

@LastDragon-ru You may want to fix the typo 😄 in your tsconfig.json it is written with a hyphen. ,

but thats the wrong way.

Do this.

cheers flash ⚡

The usage of tsconfig path mappings can be problematic for a library, as those path mappings won’t generally be available in an app that consumes the library (it has to repeat them in the app’s tsconfig). It can only work if the path mappings line up with the library name and scope.

Never claimed it otherwise @JoostK . The average developer shouldn’t have the need to bother with path mappings at all.

However, some folks maintain the opinion, that It’s a good idea to refactor an application into separate libraries within the same repo. Apparently they see a bigger benefit than the overhead the libraries come with (additional build steps).

Another valid, but barely known, use case is when working with UMD format. This way, the paths don’t matter anymore at runtime. Instead, it works with the UMD id’s. I’m currently even playing around with ESM format, which works pretty well. By using importmaps, I can easily re-map the import paths according to my needs at runtime, too. Even though it’s still a draft, you can polypill it for every major browser.

B2T: The reason why I mentioned the path mappings is because nearly no one, who opens an issue, wants to hear that the underlying problem is usually something else and that they wouldn’t have the issue at all, if they would have applied best practices. I mean, an import like

../../../../../../../../../../../../Component

doesn’t happen overnight. Regardless of whether the webpack build supports absolute paths, people should have started to think about structure, cohesion, complexity, etc. long before arriving such circumstances.

Seems like Conway’s law is still a common challenge 💩

cheers flash ⚡