Ng-packagr: [Question] secondary entry points and injectable symbols

[babeal]

Type of Issue

[x] Question

Description

We are using secondary entry points per component which builds like the material library does. Access between components is done using typescript path mappings so that the umd bundles of the components have the proper references i.e. import { service } from @ou/library/core. What's strange is that if a component in the library imports the service shown above from that path and the application using the library imports the module that provides the service from the path @ou/library, the symbol can't be found. In the injector I end up seeing service$ and service$$ which suggests that angular sees those as two separate tokens even though it should only be one. This happens for both service types and injection tokens. I am assuming this is due to the difference in path that the application imports and how component within the library import shared services between each other but I am not sure. I have tried several things, but the only way it will work is if i import the module from the secondary entry point path and not the root path.

So is what I am seeing an issue?
Is this type of build supported with ng-packagr, where I can have separate entry points per component for the umd construction but still import at the root of the package for projects that will use the esm and fesm bundles?

The bundle output seems correct. I am just don't know enough about the symbol resolver for the injector and how it determines the symbol for an token or service.

[babeal]

Ok after a little more investigation, the output produces a esm5 module for the root package and ones for each sub module. The submodule packages are correct, the root package isn't. It contains all the code for the package and the submodules. So when a submodule imports another submodule the reference to that submodule and the reference to the one exported by the package are different which causes the duplicate symbols. After reading some other github issues this approach doesn't seem to be supported. However, you are really close. The only thing that needs to be different is that the root package module should import and reexport the individual submodule packages. Maybe the idea of submodules and this idea are different and needs a different name. But what we are trying to accomplish is to provide an esm build and individual component umd bundles for projects that want to load externally from a cdn. While this can be solved with separate projects and separate builds it would be nice to support this approach within a single project.

Note: I thought i would be smart by importing by module path in the module.ts and public.api and the submodules build but the main module doesn't. It looks like the converted symbols that are exported aren't unique across submodules. So the only errors I get are things like "@sdo/web-components/activities-calendar" has already exported a member named 'ɵa'. Consider explicitly re-exporting to resolve the ambiguity. So it looks like we will undo all this work and go back to a single module unless I hear otherwise.

[babeal]

@ffriedl89 I was reading your open issue regarding memory and your setup looked close to ours. The problem we ran into is that the main module which would reexport all of the submodules was including all of the code when it should have just imported the submodules. How did you get around this? Or are you only importing your library my sub module/path references and not from the root of your package?

[babeal]

@dherges it turns out we need this to work quite badly. We noticed that the angular-cli/webpack 4 doesn't treeshake/remove external dependencies from a library build as fesm. So if my library has two components, a button and a date field, where the date field imports moment.js and i only import the button into my application moment.js is include in the final bundle. The use of sideEffects: false in both the library and moment.js didn't have any effect.

It would be nice for ng-packagr to detect sub packages underneath the primary entry point and not bundle these into the main package. The result would be that the public_api.ts -> index.js compilation would just contain references to the sub-packages instead of compiling them into the bundle. Basically this is the only part of the process that doesn't work. Is there another way?

[patrickmichalina]

Ugh. This is causing us issues with Universal/Server/Browser differences in our modules. The work around we've been using is instead of InjectionToken just using simple strings as the DI symbol. Combined with different folders + symlinks able to separate out packages but kind use the same references.

Angular 8 breaks this since string tokens are no longer allowed.