[AoT] Bundled metadata does not reflect metadata lowering // [PREV: Packaged library is not working in AOT mode]

[darkbasic]

Type of Issue

[x] Bug Report
[ ] Feature Request

Description

I get the following error if I try to use my library in another project with ng serve --aot:

ERROR in Error: Error encountered resolving symbol values statically. Calling function 'ɵa', function calls are not supported. Consider replacing the function or lambda with a reference to an exported function, resolving symbol SelectableListDirective in /home/niko/WebstormProjects/new-tutorial/whatsapp-client-angularcli-material/node_modules/ngx-selectable-list/ngx-selectable-list.d.ts, resolving symbol SelectableListDirective in /home/niko/WebstormProjects/new-tutorial/whatsapp-client-angularcli-material/node_modules/ngx-selectable-list/ngx-selectable-list.d.ts, resolving symbol SelectableListDirective in /home/niko/WebstormProjects/new-tutorial/whatsapp-client-angularcli-material/node_modules/ngx-selectable-list/ngx-selectable-list.d.ts

How To Reproduce

Just use this repo to build the package and import it in a new angularcli project:
https://github.com/darkbasic/ngx-selectable-list/tree/packagr

If you want to see how exactly I use it have a look at this repo:
https://github.com/Urigo/whatsapp-client-angularcli-material/tree/master-step6

Precisely look at Step 6.1 and Step 6.2 in the commit history.

Expected Behaviour

Should be able to use my library in AOT mode.

Version Information

ng-packagr: ^2.0.0-rc.5
@angular/*: ^5.0.0
typescript: ~2.4.2
rxjs: ^5.5.2
node: 9.2.0
npm/yarn: 5.6.0

https://github.com/darkbasic/ngx-selectable-list/blob/packagr/package.json

[bdoucette]

I am having the same issue

[dherges]

@bdoucette Good. Do you like to share your solution?

[dherges]

Uploaded the *.metadata.json files generated by packagr and by ngc:

https://gist.github.com/dherges/762563c1bf3f4448370110072a1c4656

Does someone the where the issue is? Is it this?

packagr:

  "origins": {
    "SelectableListModule": ".\/src\/app\/selectable-list\/selectable-list-module",
    "\u0275a": ".\/src\/app\/selectable-list\/directive\/selectable-list\/selectable-list.directive",
    "SelectableListDirective": ".\/src\/app\/selectable-list\/directive\/selectable-list\/selectable-list.directive",
    "\u0275b": ".\/src\/app\/selectable-list\/directive\/selectable-item\/selectable-item.directive"
  }

ngc:

  "origins": {
    "SelectableListModule": ".\/src\/selectable-list-module",
    "SelectableItemDirective": ".\/src\/directive\/selectable-item\/selectable-item.directive",
    "\u0275a": ".\/src\/directive\/selectable-list\/selectable-list.directive",
    "SelectableListDirective": ".\/src\/directive\/selectable-list\/selectable-list.directive"
  }

[georgiee]

Hello @dherges
this error is hunting me for weeks now so I wanted to prepare a minimal reproducible example located here https://github.com/georgiee/ng-packagr-foos and post it as an issue. Before I do that I wanted to check the current state of this problem.

I pinned my version of ng-packagr to 1.6.0. I thought maybe you have addressed the problem in your different release candidates in the meantime. But even with the latest RC 11 I get the very same error when creating an AOT build.

Do you have an official issue where you could link all appearances of this error,
would it help to create such an issue so you can just link to it whenever it surfaces ?

Did you already had some time to dive into the problem and have a clue what might cause this?

And thank you so much for this tool and all the conventions you guys worked out. That's so much better than maintaining your own packaging madness 🙌

[dherges]

Hi @georgiee,

thanks for putting a good repro up! That helps to give you some feedback. In your case...

In the repro at https://github.com/georgiee/ng-packagr-foos, the bundled metadata json (scoped-some-name.metadata.json) has no metadata for FooModule and FooComponent. But, these two are exported by the FESM bundles ((esm5|esm2015)/scoped-some-name.js).

I guess this issue is angular/angular#21082 - let's ask

[georgiee]

Hey @dherges,
thanks for connecting the dots and taking that issue to that Angular issue. Looks indeed the same. Let's see what's happening over there.

[darkbasic]

Hi,
I just wanted to let you know that I managed to "workaround" the issue such a way:

--- a/src/app/selectable-list/directive/selectable-list/selectable-list.directive.ts
+++ b/src/app/selectable-list/directive/selectable-list/selectable-list.directive.ts
@@ -21,12 +21,14 @@ export enum Mode {
   both = 'Single and multiple (press activated)',
 }
 
+export const SERVICE = new SelectableListService();
+
 @Directive({
   selector: '[appSelectableList]',
   providers: [
     {
       provide: 'selectable-list-service',
-      useValue: new SelectableListService(),
+      useValue: SERVICE,
     }
   ],
 })

I don't know if that could be applicable to any of your use cases.

[georgiee]

Hello @dherges,
I have an explanation for this issue. Those stupid barrels in Typescript were killing it again 🙄 I bet that's the reason for many issues as it just silently fails to generate the metadata.

See this?
georgiee/ng-packagr-foos@6e9f1c7#diff-393c1bcd1bbb4c9e013383245aec1691R2

Go from

export * from './foo'; 

to

export * from './foo/index'; 

and this will fix the metadata issue not only in this small example but also in my real library 🙏 Hope this enables you to help people coming here with this error.

Source of my knowledge:
https://codewithstyle.info/creating-angular-npm-packages-with-ng-packagr/

---

IGNORE the following unrelated error:
fixed with ng serve --preserve-symlinks as I linked the library locally. Without a symlinked folder there is no issue. With a symlink use the flag.

Original question I had:
I'm now only left with a runtime StaticInjectorError when I use a component that injects ElementRef from my compiled library. Hope this is not related to the library build. 🤞

// In my lib being compiled
export class TestComponent {
  constructor(
    public elementRef: ElementRef
  ) { }
}

// In the consumer
/*
Error: StaticInjectorError(AppModule)[FooComponent -> ElementRef]: 
  StaticInjectorError(Platform: core)[FooComponent -> ElementRef]: 
    NullInjectorError: No provider for ElementRef!
Stack trace:
_NullInjector.prototype.get@webpack-internal:///../../../core/esm5/core.js:1209:19
*/

[dherges]

Hi there,

regarding TypeScript barrels, there are some known issues, see #195. I cannot say why when and how the issues come up. In general, my personal recommendation is to not use TypeScript barrels.

Regarding the StaticInjectorError, I am keeping fingers crossed that someone will eventually be able to reproduce the issue and post a link to a github repository (or similar).

[dherges]

I'd like to emphasize on the following quot from the above blog post:

It turns out that you cannot do this! All the providers should be included in generated metadata and in this case, the final provider list will only be known at runtime so it’s not possible to figure it out during compile time. Therefore, it’s not possible to implement such scenario. The providers array has to be determined statically.

If you're intending to provide a module in different "feature-configurations", my recommendation is to do so by .forFeatureA():ModuleWithProviders, .forFeatureB(): ModuleWithProviders, and so on. Another (architectural) alternative is to pass a configuration object to services; in that case, providers would be the same for feature A and for feature B and the service implmentation will be "kind-of-context-sensitive" and respond to the feature configuration. For example, ngx-bootstrap utilizes that approach by providing "configuration as a service"

[villecoder]

In my case, I had this error crop up when I was exporting a service that used an InjectionToken and a factory. I had to explicitly export the injection token constant with the module and factory in the library's main index.ts in order to get things to work.

[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.}