Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upfix(@schematics/angular): exclude es5 bundles from being prefetch #17905
Conversation
|
This is definitely a step in the right direction. It would be even better imo if we could adapt the |
| @@ -11,7 +11,8 @@ | |||
| "/index.html", | |||
| "/manifest.webmanifest", | |||
| "/*.css", | |||
| "/*.js" | |||
| "/*.js", | |||
| "!/*-es5*.js" | |||
gkalpak
Jun 11, 2020
Member
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.
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
Jun 11, 2020
Author
Good point
Good point
alan-agius4
Jun 11, 2020
Collaborator
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?
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
Jun 11, 2020
Collaborator
In version 10 differential loading is on opt-in basis.
In version 10 differential loading is on opt-in basis.
alan-agius4
Jun 11, 2020
Collaborator
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.
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
Jun 11, 2020
Member
So, what is the plan for differentiating es5 bundles vs es20XX bundles in v11?
So, what is the plan for differentiating es5 bundles vs es20XX bundles in v11?
alan-agius4
Jun 11, 2020
Collaborator
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...
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
Jun 11, 2020
Author
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 :).
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 :).
One downside of doing so is that in my case I enabled the Angular Service Worker (and applied the Also I believe that the Angular CLI is now setting the target to |
…n differencial loading is used
laurentgoudet
force-pushed the
laurentgoudet:fix-double-prefetch
branch
from
6b6b4b4
to
6fef6de
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.jsontemplate 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 defaultngsw-config.jsonconfig can just be modified) compared to current double fetching.In addition:
<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).ngsw.jsonconfig for these browsers (nor the Angular CLI has support to built it), and realistically will never need to.