Skip to content

PB-1878: service worker versioning start#1564

Draft
sommerfe wants to merge 6 commits intodevelopfrom
feat-pb-1878-version-service-worker
Draft

PB-1878: service worker versioning start#1564
sommerfe wants to merge 6 commits intodevelopfrom
feat-pb-1878-version-service-worker

Conversation

@sommerfe
Copy link
Contributor

@sommerfe sommerfe commented Feb 3, 2026

Service Worker Files and Workflow (Build + Runtime)

Files involved

  • packages/mapviewer/src/service-workers.ts

    • Source Service Worker code (Workbox routes and caching strategies).
  • dist/service-workers.js (root)

    • Stable Service Worker entrypoint used by browser registration (./service-workers.js).
  • dist/<appVersion>/service-workers.js

    • Versioned Service Worker implementation for a specific release.
  • dist/<appVersion>/sw-ready.json

    • Build validation artifact written by custom plugin (vite-plugin-version-sw-path).

Build-time workflow

  1. VitePWA builds the SW

    • Compiles service-workers.ts into dist/service-workers.js (and optional map).
  2. vite-plugin-move-sw runs

    • Copies dist/service-workers.jsdist/<appVersion>/service-workers.js.
    • Rewrites root dist/service-workers.js as bootstrap:
      • importScripts('./<appVersion>/service-workers.js')
    • Optionally copies sourcemap.
  3. vite-plugin-version-sw-path runs

    • Scans built chunks for SW registration path usage ("./service-workers.js").
    • Writes dist/<appVersion>/sw-ready.json with validation metadata.

What each file does

  • Root service-workers.js

    • Keeps a stable registration URL and scope behavior.
  • Versioned /<appVersion>/service-workers.js

    • Holds the actual SW logic for that release.
  • sw-ready.json

    • Diagnostic/validation metadata (swVersioned, version, timestamp, etc.).
    • In current setup, it is not used at runtime unless explicitly read elsewhere.

Runtime workflow (when user opens app)

  1. App registers SW at ./service-workers.js.
  2. Browser fetches root SW script.
  3. Root script imports versioned SW via importScripts.
  4. SW installs/activates:
    • precache (self.__WB_MANIFEST)
    • runtime routes (navigation/config/images)
    • skipWaiting() + clientsClaim() for fast takeover
  5. Subsequent loads use cache/network strategies (mostly NetworkFirst in your code).

Why versioning matters

  • Most relevant during deployments/updates.
  • New release changes root SW bootstrap to point to new versioned SW file.
  • Browser detects SW script update at same registration URL.
  • New SW installs/activates and replaces previous behavior/caches.

Test link

@sommerfe sommerfe self-assigned this Feb 3, 2026
@cypress
Copy link

cypress bot commented Feb 3, 2026

web-mapviewer    Run #6521

Run Properties:  status check passed Passed #6521  •  git commit 14225c952a: PB-1878: add translations
Project web-mapviewer
Branch Review feat-pb-1878-version-service-worker
Run status status check passed Passed #6521
Run duration 07m 14s
Commit git commit 14225c952a: PB-1878: add translations
Committer Felix Sommer
View all properties for this run ↗︎

Test results
Tests that failed  Failures 0
Tests that were flaky  Flaky 0
Tests that did not run due to a developer annotating a test with .skip  Pending 20
Tests that did not run due to a failure in a mocha hook  Skipped 0
Tests that passed  Passing 261
View all changes introduced in this branch ↗︎

@sommerfe sommerfe force-pushed the feat-pb-1878-version-service-worker branch 2 times, most recently from 6ff5242 to f017012 Compare February 3, 2026 13:15
@sommerfe sommerfe marked this pull request as draft February 3, 2026 14:00
@sommerfe sommerfe force-pushed the feat-pb-1878-version-service-worker branch 21 times, most recently from 77eec5e to 89d3caa Compare February 25, 2026 14:57
@sommerfe sommerfe requested a review from Copilot February 26, 2026 07:02
Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR implements service worker versioning by moving the generated service worker file into a versioned directory structure. The implementation adds two new Vite plugins to handle the versioning process and updates the application to validate the service worker configuration at runtime.

Changes:

  • Added two new Vite plugins: one to validate service worker registration patterns and emit a validation file, another to move the service worker to a versioned directory with a bootstrap loader
  • Updated build info generation to include service worker path information based on build mode
  • Enhanced offline readiness status component to validate SW configuration, handle insecure contexts, and display appropriate error states
  • Refactored service worker to use import.meta.env.MODE instead of IS_TESTING_WITH_CYPRESS and conditionally register navigation routes only in non-dev builds

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 7 comments.

Show a summary per file
File Description
packages/mapviewer/vite.config.mts Added imports and configuration for new SW versioning plugins, passed mode parameter to build info plugin, added console logging for build mode
packages/mapviewer/vite-plugins/vite-plugin-version-sw-path.js New plugin that validates SW registration patterns in build output and emits a validation JSON file
packages/mapviewer/vite-plugins/vite-plugin-move-sw.js New plugin that moves the generated SW file to a versioned directory and creates a bootstrap loader at the root
packages/mapviewer/vite-plugins/vite-plugin-generate-build-info.js Updated to accept mode parameter and include SW path information in build info output
packages/mapviewer/src/utils/offline/OfflineReadinessStatus.vue Added SW validation checking, insecure context detection, error state management, and updated UI to display various SW states
packages/mapviewer/src/service-workers.ts Replaced IS_TESTING_WITH_CYPRESS with import.meta.env.MODE check, added log statements, and made navigation route registration conditional on non-dev mode
packages/mapviewer/tests/cypress/tests-e2e/featureSelection.cy.js Removed unnecessary blank line

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Copilot reviewed 7 out of 7 changed files in this pull request and generated 3 comments.


💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

@sommerfe sommerfe force-pushed the feat-pb-1878-version-service-worker branch 2 times, most recently from e315d5a to a7dd498 Compare February 26, 2026 11:08
@sommerfe sommerfe requested review from ltkum, ltshb and pakb February 26, 2026 12:32
Copy link
Contributor

@pakb pakb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looking good so far, I have one general question about the second plugin

I think we should translate all the text you've added to the Vue component too (but I'm guessing you were waiting for a technical review first)

Comment on lines +1 to +9
/**
* Vite plugin that validates the service worker registration path and emits a build validation file.
*
* This plugin:
* 1. Finds chunks containing service worker registration code from the virtual:pwa-register module
* 2. Validates that the registration path remains "./service-workers.js" (root scope-safe path)
* 3. Emits a validation file (sw-ready.json) to indicate successful configuration
* 4. Warns if no SW registration pattern is found (validation failure)
*/
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is exactly the problem that this plugin is trying to detect?
A failed build?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The plugin moves the service-worker.js file to ${appVersion}/service-workers.js if this was not successful, it logs the warning but it will not make the build fail

Copy link
Contributor

@pakb pakb Feb 27, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So in case this sw-ready.json isn't created, the build doesn't fail and continue its course. Then the app loads that and does not activate SW at all because of the missing file? So it kind of revert back to simple load of the page?

I'm not 100% sure how this will behave whilst having already cached/loaded SW environment in the browser though

I'm a bit afraid the browser will stick to its latest valid version it has in the cache

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The sw-ready.json file does not have any functionality regarding the service worker itself, it is only there for the OfflineReadinessStatus.vue to show an error if the service worker validation failed, but the service worker is working independently from it.

The browser uses normal SW lifecycle: install -> waiting/active -> claim/update.
If the new /service-workers.js is reachable and changed, it can update to the new service worker.
If the update path is broken, browser keeps last valid active SW

btw i noticed when i tested on the phone, that the offline readiness status is not visible on mobile, where it is mostly used, so we might want to add that on the mobile view

@sommerfe sommerfe force-pushed the feat-pb-1878-version-service-worker branch from 9fd379a to 9770a0a Compare February 27, 2026 08:42
@sommerfe sommerfe force-pushed the feat-pb-1878-version-service-worker branch from 9770a0a to 8ea660e Compare February 27, 2026 12:03
@sommerfe sommerfe force-pushed the feat-pb-1878-version-service-worker branch from 8ea660e to 14225c9 Compare February 27, 2026 12:31
@sommerfe sommerfe requested a review from pakb February 27, 2026 14:02
Copy link
Contributor

@ltshb ltshb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think @pakb can review this better than I do

Copy link
Contributor

@pakb pakb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM so far, what I propose we do, if you think this could be ready to be tested "live" is that we could ship this change as a single version (no other changes).
This way we can quickly rollback if we see it's not behaving as planned

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants