APP_INITIALIZER provider fails to load from library module in production build
See original GitHub issueI’m submitting a…
[ ] Regression (a behavior that used to work and stopped working in a new release)
[x] Bug report
[ ] Performance issue
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question
[ ] Other... Please describe:
Current behavior
I have a provider that is supposed to load on init, using the APP_INITIALIZER token. This provider is defined within the module declaration of the Angular 6 library. With dev builds, the provider loads as expected, but when running “ng serve --prod”, Angular generates this error:
ERROR TypeError: this.appInits[r] is not a function
This appears to happen in the line var initResult = this.appInits[i]();
in the ApplicationInitStatus.runInitializers() function. Stepping into this code, the value at the this.appInits index is undefined. When running in dev mode, this same index is a function(), as expected by the code.
ApplicationInitStatus.prototype.runInitializers = function () {
var _this = this;
if (this.initialized) {
return;
}
var asyncInitPromises = [];
var complete = function () {
_this.done = true;
_this.resolve();
};
if (this.appInits) {
for (var i = 0; i < this.appInits.length; i++) {
var initResult = this.appInits[i]();
if (isPromise(initResult)) {
asyncInitPromises.push(initResult);
}
}
}
Promise.all(asyncInitPromises).then(function () { complete(); }).catch(function (e) { _this.reject(e); });
if (asyncInitPromises.length === 0) {
complete();
}
this.initialized = true;
};
This error happens, regardless of how simple the provider is. For example, below is a simple provider that exhibits the same problem when loaded within the Angular library module.
export function initializeApp() {
return () => new Promise((resolve, reject) => {
console.log(`initializeApp:: inside promise`);
setTimeout(() => {
console.log(`initializeApp:: inside setTimeout`);
// doing something
resolve();
}, 3000);
});
}
And this is the config in the module’s providers array:
{
provide: APP_INITIALIZER,
useFactory: initializeApp,
multi: true
},
If I take this same code and bring it out to the enclosing application’s module declaration, the provider loads without error in prod mode. This only seems to affect providers loaded in a library module in a production environment.
Expected behavior
I expect the production build would behave the same as the dev build, and load the provider correctly during app initialization.
Minimal reproduction of the problem with instructions
Create an Angular application with a separate library module, adding in the above provider to the library’s module declaration, and adding that library module to the application.
What is the motivation / use case for changing the behavior?
Consistent APP_INITIALIZER behaviour for all providers, regardless of location in the application code.
Environment
Angular version: 6.0.9
Browser:
- [x] Chrome (desktop) version 67
- [ ] Chrome (Android) version XX
- [ ] Chrome (iOS) version XX
- [x] Firefox version 60
- [ ] Safari (desktop) version XX
- [ ] Safari (iOS) version XX
- [ ] IE version XX
- [ ] Edge version XX
For Tooling issues:
- Node version: XX
- Platform:
Others:
Issue Analytics
- State:
- Created 5 years ago
- Reactions:2
- Comments:5 (2 by maintainers)
The issue has proved troublesome to reproduce. It appeared to be related to the public-apis file, but the issue seemed to fix itself before I could narrow down the issue to something reproducible. That said, that Angular internal appInits array in runInitializers() should either be checking for undefined instead of throwing the non-helpful error described above, or else code elsewhere in Angular that is rejecting the problematic initializer shouldn’t be shoving undefined into the array in the first place.
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.