We’re currently using an old QuickJS and we’d like to upgrade. The gotcha is that each QuickJS version has its own mutually-incompatible bytecode.

We’ll need to change our Gradle plugin to build a .zipline file for each supported version:

• The existing Zipline 20211020, which uses QuickJS 2021-03-27
• A new Zipline 20250913, which would use QuickJS 2025-09-13
• And someday soon, hopefully a Zipline 20260401 that uses Wasm 3.0.

We’ll also need to change manifest JSON to support multiple bytecode versions. Perhaps like this:

 {
   "unsigned": { ... },
   "modules": {
     "./hello.js": {
       "url": "hello.zipline",
       "sha256": "981d714f8773b205e317d844486eb40953eda148fb5836179ecb8301ba29fd76",
       "dependsOnIds": []
     },
     "./app.js": {
       "url": "app.zipline",
       "sha256": "6d1243212d19f60bf2741b49982690185d8baeac776cb0fa49fd013a791693e8",
       "dependsOnIds": []
     }
   },
+  "modules/20250913": {
+    "./hello.js": {
+      "url": "hello.20251010.zipline",
+      "sha256": "6eb40953eda148fb5836179ecb8301ba29fd76981d714f8773b205e317d84448",
+      "dependsOnIds": []
+    },
+    "./app.js": {
+      "url": "app.20251010.zipline",
+      "sha256": "5d8baeac776cb0fa49fd013a791693e86d1243212d19f60bf2741b4998269018",
+      "dependsOnIds": []
+    }
+  },
   "mainModuleId": "./app.js",
   "mainFunction": "zipline.ziplineMain",
   "version": null,
   "metadata": {}
 }

Old app’s Zipline loaders would ignore the new modules/20250913 property, and new app’s Zipline loaders would ignore the old modules property. Only the compiler plugin would have to handle both!

The drawbacks of supporting N versions:

• Having to wait for N executions of the Zipline compiler in CI. It’s pretty fast so that’s no big deal.
• Having N times as much data to store in our CDN. That’s also not that big of a deal.

But we should configure the hot-reloading plug-in to only build a single version.