fix(@schematics/angular): exclude es5 bundles from being prefetch

[laurentgoudet]

Fixes angular/angular#31256.

When differential loading is used, by default the Angular Service Worker will double-(pre)fetch the ES5 & ES2015 bundles, unless those are explicitly excluded as per angular/angular#31256 (comment).

Excluding those ES5 bundles from the ngsw-config.json template would provide a better developer experience, removing the risk of double fetching the JS bundles when differential loading is used/enabled, while having no impact when differential loading isn't used.

Doing so would prevent browsers with Service Worker support but without <script type="module"> support to prefect the correct JS bundles, but I'd argue the tradeoff is acceptable (and the default ngsw-config.json config can just be modified) compared to current double fetching.

In addition:

• the few browser versions that support Service Workers but not <script type="module">, which according to https://caniuse.com/#feat=es6-module & https://caniuse.com/#feat=serviceworkers are basically Firefox < 60 (current is 76), Chrome < 61 (current is 83), Opera < 48 (current is 68), are all outside Angular's browser support ranges (and outdated).
• the Angular Service Worker has also no support to load a different (es5) ngsw.json config for these browsers (nor the Angular CLI has support to built it), and realistically will never need to.

[gkalpak]

This is definitely a step in the right direction.

It would be even better imo if we could adapt the ngsw-config.json template to the TS config target. Is it possible to do that, @alan-agius4?

[gkalpak]

If we are doing it, then we should also lazily cache the /*-es5*.js bundles (as shown in angular/angular#31256 (comment)).
There is no overhead for es2015 supporting browsers.

[laurentgoudet]

Good point

[alan-agius4]

It would be even better imo if we could adapt the ngsw-config.json template to the TS config target. Is it possible to do that, @alan-agius4?

A different tsconfig can be specified for each configuration. An application can various tsconfig, though this is probably not the norm.

That said, differential loading though is not only controlled via the target specified in the tsconfig, but also the result of the browserslists query.

@gkalpak, what would we the value to generate a different ngsw-config.json?

[alan-agius4]

In version 10 differential loading is on opt-in basis.

[alan-agius4]

I actually have some concerns about adding this.

For the reasons, that in version 11 we might want to change the generated bundle names not to have the syntax target as part of the filename.

See for more context: #17630 (review)

This would means that by adding this, we'd need to do a migration to migrate existing projects and replace the negate pattern.

[gkalpak]

So, what is the plan for differentiating es5 bundles vs es20XX bundles in v11?

[alan-agius4]

It hasn't been decided yet.

There are two 2 main option here, either leave the script target in the filename or change the filename not to contain it and use generic terms, like 'modern', legacy' etc...

[laurentgoudet]

This would means that by adding this, we'd need to do a migration to migrate existing projects and replace the negate pattern.

v11 is still many months away though, so while I do agree that not having es2015 in the bundle names is more future proof I think there is some value in introducing that logic now & doing a migration when v11 lands, especially as double (pre)fetching by the Angular Service Worker can be hard to detect when not looking for it.

Having said that I'll likely won't be the one writing the v11 migration code so I completely understand if you want to postpone that for now, and I'll try not to forget to update my ngsw-config.json for v11 :).

[laurentgoudet]

It would be even better imo if we could adapt the ngsw-config.json template to the TS config target. Is it possible to do that, @alan-agius4?

One downside of doing so is that in my case I enabled the Angular Service Worker (and applied the @angular/service-worker schematic) before turning differential loading on, i.e. before bumping the TS config target.

Also I believe that the Angular CLI is now setting the target to es2015 by default (and enabling differential loading), so there might not be a strong use case for using the TS config target, especially as excluding /*-es5*.js has no effect when the target is set to es5, since then the JS bundle names don't have the -es5/-es2015 suffixes.

[dgp1130]

We were going through some old PRs and came across this one. Differential loading is in a slightly different place now, since is deprecated and disabled by default. The main motivation for it is IE11, whose support is also deprecated and likely going away in Angular v13. As a result, we think it's better to avoid investing too much energy into a feature like differential loading which is on its way out the door. Skipping this also means we don't have to worry about migrating existing apps to/from this format, which makes removing differential loading a little easier.

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