Unable to acquire PlatformRef and ModuleRef with aot during bootstrap

[EricABC]

Very similar to #8234

Bug Report or Feature Request (mark with an x)

- [ X ] bug report -> please search issues before submitting
- [ ] feature request

Versions. ng-cli@rc-8, ng@rc-9

Repro steps.

The following bootstrap code worked somewhere around rc-3 and down:

environment.ngPlatformRef = platformBrowserDynamic();
environment.ngPlatformRef.bootstrapModule(AppModule).then(r => environment.ngModuleRef = r);

The log given by the failure.

Same templateUrl 404's as #8234.
http://localhost:4200/material.component.html 404 (Not Found)

Desired functionality.

The desire is to have the ability to tear down an angular application, as our front end separates behavioral services in a separate parallel application from the angular application. This is done by calling the dispose methods on the module and platform (some detail found in issue for known memory leak: angular/angular#13725). I have tried a few forms of capturing these to no avail (settings to constants first, etc...). As soon as I give up the concern for tearing the ng app down, the standard platformBrowserDynamic().bootstrapModule(AppModule) works fine.

[filipesilva]

This happens due to the way we try to replace the bootstrap code for AOT. We look for platformBrowserDynamic().bootstrapModule(AppModule) and that detection is not flexible enough to allow for this sort of indirection.

[EricABC]

This was fixed, thanks.

[EricABC]

Oops, stupid mistake on my part. It still is an issue.

[mgechev]

Are you still able to reproduce this issue with the latest version?

[EricABC]

Yup, you can drop this into an 'ng new' main.ts and then run with --aot. This was 7.2.0-rc.0 and errors out here. Everything runs fine without aot.

const ngPlatformRef = platformBrowserDynamic();
let ngModuleRef: NgModuleRef<AppModule>;
ngPlatformRef.bootstrapModule(AppModule).then(r => ngModuleRef = r);

[alexzuza]

@EricABC
What about this option?

import { getPlatform, NgModuleRef, PlatformRef } from '@angular/core';
import { platformBrowserDynamic } from '@angular/platform-browser-dynamic';

let ngPlatformRef: PlatformRef;
let ngModuleRef: NgModuleRef<AppModule>;

platformBrowserDynamic().bootstrapModule(AppModule)
  .then(r => {
    ngModuleRef = r;
    ngPlatformRef = getPlatform(); // or r.injector.get(PlatformRef);
  });

[EricABC]

Thanks for the suggestion. Although this works, it couples the synchronous entry point and resource allocation of angular with the asynchronous application resource allocation. I think there is value in separating the angular context (platform) from the developer context (app bootstrapping). If an angular app fails to bootstrap, there is a way to recover the 'outer' app. This could be useful for any situation where angular works in harmony with other external entry points, frameworks, tooling apps that assist in angular development, etc...

Actually, I was starting to write a proposal to PR this, but Ivy looks like it's being designed to handle more complex use cases, including multiple root nodes and root contexts. I'm thinking that any work here might be short-lived. I'm happy closing this as out of scope, or if desired I could still PR. If you want the PR, I would implement by creating a separate entrypoint discovery context class that explicitly maps SyntaxKind.Identifier entryModuleIdentifiers to imports, discovers variable assignments, and ultimately replaces the expressions. replaceBootstrap and replaceServerBootstrap would both use this class to map one or more entrypoints.

[EricABC]

Actually, I tried this and I was able to access and dispose the platform properly at both a synchronous failure (ie. module constructor throws) and an async failure (ie. a component constructor throws).

try {
  platformBrowserDynamic().bootstrapModule(AppModule).catch(e => {
    console.log('async');
    getPlatform().destroy();
  });
} catch (err) {
  console.log('sync');
  getPlatform().destroy();
}

I'd close this, but i'll leave it to you guys since its marked with a higher priority, or if you wanted the PR anyway to support more entrypoint syntax.

[filipesilva]

I think the approach you are suggesting should be ok. We try to avoid adding more bootstrap patterns because they are brittle by nature.

[angular-automatic-lock-bot]

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