fix(@schematics/angular): enable lazy loading with ivy

[cexbrayat]

Angular 8.0.0-beta.1 supports lazy loading with Ivy (at least a partial support), but currently the CLI needs "allowEmptyCodegenFiles": true to avoid errors like:

ERROR in ./src/$$_lazy_route_resource lazy namespace object
Module not found: Error: Can't resolve '/src/app/races/races.module.ngfactory.js' in '/src/$$_lazy_route_resource'

As discussed with @gkalpak this might be a temporary workaround, but it might help users giving a try to Ivy (as the workaround is not really trivial ^^) .

[gkalpak]

Related Jira issue: FW-737

[alan-agius4]

The last time I talked to @IgorMinar, he mentioned that we should NOT enable this by default. So I am going to wait for his feedback.

[IgorMinar]

do we understand the root cause of the problem?

is the problem that the web pack pipeline expects the factories to be around for the lazy loading to work?

Originally I thought that we would always need factory shims to be generated by default, but in reality we need this only in google3 where the pipeline works differently from external webpack-based cli.

Unless I'm mistaken, we don't ever scaffold any kind of code that references factories directly. Both the bootstrap and router lazy loading in the ngc/view-engine pipeline swap factories for components behind the scenes, so the developer never interacts with them directly. If this is the case, then we should not generate factories with ivy at all and instead focus on fixing whatever it is that is causing the lazy loading in CLI to fail today.

I see that @gkalpak added this flag to his aio PR as well: https://github.com/angular/angular/pull/26947/files#r251221208

it's ok to use the flag as a workaround, but we shouldn't start scaffolding new projects with it, even if it's an option behind the ivy flag.

btw the main reason for not generating the shims is that they cause lots of headaches within webpack, make code splitting and tree-shaking less reliable, slow down the build, and just add noise to the build output. this is why we should try to disable them by default in ivy and only tell users to enable them if they somehow directly using factories in the existing code (as is the case in google3).

[alan-agius4]

Hi Igor, I didn’t look into this recently, but in the webpack pipeline, we do change the modules and file paths to factories when not having a jit compilation. We should definitely change this and do only so for AOT and when enabling factories shimming. However, I doubt that lazy loading will work in ivy without factories because of the SystemJsNgModuleLoader in core, as it always expects to have factories https://github.com/angular/angular/blob/master/packages/core/src/linker/system_js_ng_module_factory_loader.ts

…

On Sun, 27 Jan 2019 at 05:45, Igor Minar ***@***.***> wrote: ***@***.**** requested changes on this pull request. do we understand the root cause of the problem? is the problem that the web pack pipeline expects the factories to be around for the lazy loading to work? Originally I thought that we would need factory shims to be generated by default, but in reality we need this only in google3 where the pipeline works differently from cli. Unless I'm mistaken, we don't ever scaffold any kind of code that references factories directly. Both the bootstrap and router lazy loading in the ngc/view-engine pipeline swap factories for components behind the scenes, so the developer never interacts with them directly. If this is the case, then we should not generate factories with ivy at all and instead focus on fixing whatever it is that is causing the lazy loading in CLI to fail today. I see that @gkalpak <https://github.com/gkalpak> added this flag to his aio PR as well: https://github.com/angular/angular/pull/26947/files#r251221208 it's ok to use the flag as a workaround, but we shouldn't start scaffolding new projects with it, even if it's an option behind the ivy flag. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#13524 (review)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AQv-WiLe_kvTPOYwBdcoDc2qsn87PaWgks5vHS7cgaJpZM4aTZlX> .

[IgorMinar]

I see.. the right solution is to change the loader so that it doesn't use the NgModuleFactoryLoader when we run in the Ivy mode:

• https://github.com/angular/angular/blob/d83307adab10ab4477715bc904401fb78bac17e9/packages/router/src/router_module.ts#L71
• https://github.com/angular/angular/blob/d83307adab10ab4477715bc904401fb78bac17e9/packages/router/src/router_module.ts#L455-L459
• https://github.com/angular/angular/blob/d83307adab10ab4477715bc904401fb78bac17e9/packages/router/src/router_config_loader.ts#L33-L59

I'm just not sure if we need to be able to handle both the scenario with Ivy on with and without factory shims.

@jasonaden should weigh in as well...

[clydin]

Can we have the Ivy AOT compiler normalize the string form to the System.import/import form? While solving this problem, it would also provide several nice value added benefits:

• In AOT mode, remove the need for the CLI to perform lazy route detection and special context webpack module mapping (a large/complex unit of code)
• Remove a class of hard to fix lazy route naming related defects such as this: [@ngtools/webpack] Webpack cannot distinguish on context and would fail to load the proper one. #10128
• Allow for more optimized bundling and potential reduced overall application bundle sizes and loading times. The lazy route hierarchy would no longer be flattened which would allow for the option of common modules to be directly included in the lowest common ancestor instead of always in separately loaded lazy bundles.

[alan-agius4]

Superseded by #13667

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