No, the issue seems to be there from a long time.
Currently, the ngsw-config.json generated with ng g service-worker or ng add @angular/pwa references absolute paths (eg. /index.html, /*.css...).
It will work fine if the app is deployed in the root directory (ie. with <base href="/").
But it will fails if the app is deployed in a subdirectory (ie. with <base href="/en/"), as absolute paths won't take base href into account.
Such base hrefs are the default scenario when using the new --localize option (CLI will set a different base href for each locale), meaning service-worker and v9 i18n don't work out of the box.
As paths in ngsw-config.json are part of the dist build, ie. from the files impacted by base href, these paths should be relative and not absolute.
ng add @angular/pwang build --prod --localizeThe service worker won't cache the app files (index.html, css, js...).
Angular CLI: 9.0.0-rc.5
Node: 12.13.1
OS: darwin x64
Angular: 9.0.0-rc.5
... animations, cdk, cli, common, compiler, compiler-cli, core
... forms, language-service, localize, material
... platform-browser, platform-browser-dynamic, router
... service-worker
Ivy Workspace: Yes
Package Version
------------------------------------------------------------
@angular-devkit/architect 0.900.0-rc.5
@angular-devkit/build-angular 0.900.0-rc.5
@angular-devkit/build-ng-packagr 0.900.0-rc.5
@angular-devkit/build-optimizer 0.900.0-rc.5
@angular-devkit/build-webpack 0.900.0-rc.5
@angular-devkit/core 9.0.0-rc.5
@angular-devkit/schematics 9.0.0-rc.5
@ngtools/webpack 9.0.0-rc.5
@schematics/angular 9.0.0-rc.5
@schematics/update 0.900.0-rc.5
ng-packagr 9.0.0-rc.3
rxjs 6.5.3
typescript 3.6.4
webpack 4.41.2
Anything else relevant?
The fix is easy: just remove the leading slash of all paths in ngsw-config.json template (including the index property).
Unfortunately, the commit that augmented the base HREF values for the service worker when using i18n did not make it into the latest RC. However, it will be present in the next release.
A review of the service worker and its interaction with both base HREF and deploy URL options is also underway which should provide additional benefit regardless of i18n usage.
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._
Most helpful comment
Unfortunately, the commit that augmented the base HREF values for the service worker when using i18n did not make it into the latest RC. However, it will be present in the next release.
A review of the service worker and its interaction with both base HREF and deploy URL options is also underway which should provide additional benefit regardless of i18n usage.