Open bwindels opened 3 years ago
How could this tie in with running sync from the service worker (separate issue, not part of this)? The only way I can think off would be to:
importScripts
the sdk, and then finds it at the same global variable.importScripts
to load its bundle though.So, we'll need a rollup plugin where we can define files where imports should be replaced with importScripts (in our case sw.js
). We'll also set it up that we have a main.js
for the sw, and we turn that into a bundle.
so we'll have:
//... service worker constants...
import {startServiceWorker} from "./main.js";
startServiceWorker();
which will be turned into
//... service worker constants...
// defines __sw_main as global variable
importScripts("sw-main-13924839.js");
const {startServiceWorker} = __sw_main;
startServiceWorker();
so we'd need to look for import
declarations in a transform hook, and transform them to a function call of importScripts
.
We'll also need to use manualChunks to set up these chunks:
ServiceWorkerPlatform
and a DOMPlatform
as SDK platforms, and a subclass of DOMPlatform
(ViewDOMPlatform
) with extensions for what the view models need (saveFileAs, ...).how about code used in sdk like the observables we (might) use in app-main as well? separate chunk?
also see https://github.com/surma/rollup-plugin-off-main-thread
seems like importScripts can work with AMD modules? Could we compile the common code to AMD and also use that for loading the SDK from the document/main thread?
But if not loading our main bundle with a <script type="module">
tag, then how do we determine whether we should load a "modern" (vs legacy) bundle? I guess can programatically determine module support and load the modern AMD bundle if that is the case. We don't actually use the module support but rather use it as a baseline for our modern browser support.
Note that vite also has support for compiling web workers, but that just throws everything in an IIFE. So it won't help us with this issue really, as going that way would make the service worker huge, which is problematic as it can't be cached.
The service worker is growing in size, so everything the browser polls for an update, it downloads the whole file. Also, the code is growing in complexity, and it is becoming hard to navigate the single large file. All the replaced variables should be defined in the file, along with an import, and the bundle with the real code should go in a file that has a content hash on it.
We want to keep the ability to run the service worker without transpilation in both latest FF and Chromium, so we need to use(can't do this anyway if we want to run sync from service worker).importScripts
We will end up using multiple files in the main import, and we would want those bundled up, so we would need to build a bundle for the service worker code that is worker-compatible (e.g. exports it symbols through a global variable) and then with the build script replace the name we do
importScripts
of in the service worker.being bundled up into
sw.js
andsw-bundle-34985934.js
. Most of the work will be in the build.mjs script, the rest in reorganizing the service worker code into multiple files.The olm worker currently isn't very big but might eventually also benefit from this.