Migrate to all-in-one SvelteKit

[Azgaar]

We have two separate projects with separate code bases:

• Armoria, client-side app
• Armoria API, an server-based API.

Fantasy Map Generator also contains a very similar code and all the charges.

It causes issues when we add new charges or change COA rendering routine. I would like to have a single repo containing both client-side code and the API.

We can migrate to SvelteKit to support the same tech stack and deploy it to Vercel to serve both static client and API. Fantasy Map Generator should use API instead of a local logic. This will make things much simpler.

[Blipz]

Would FMG still embark an instance of Armoria for offline use, or would a local Armoria installation be needed?

Also, is there any way I can help with no experience of SvelteKit/Vercel?

[Azgaar]

Yes, you can try, it's not that complex. It will still work as is if done correctly, client PWA + API layer. Client will be able to install the PWA.

[Blipz]

I started tests on migrating the Armoria codebase to SvelteKit, here are my initial remarks so far:

• using a more recent Svelte (4.2.18) version brings a bunch of accessibility warnings
• imports need to be updated to accomodate to the default SvelteKit project structure
• I had to add many conditions in the codebase to check if a browser is running (access to window, document, localStorage...), not really sure if that's normal or not
• the svelte-preprocess and rollup dependencies don't seem to be needed
• I don't know what to do about the service worker feature in main.js
• when using "npm run dev", the server loading is faster but access to the page in the browser is much slower, maybe because there are now so many JS files to load instead of one previously
• when using "npm run build" and "npm run preview", this is better

Other than that, it seems to work well.

[Azgaar]

using a more recent Svelte (4.2.18) version brings a bunch of accessibility warnings

SvelteKit should work fine with Svelte 3. Generally it's fine, we can improve accessibility later.

had to add many conditions in the codebase to check if a browser is running

We need to disable SSR (serve-side rendering) for all Armoria pages. This should ensure that the code is only run in browser and hence no need to check if it has window of not.

the svelte-preprocess and rollup dependencies don't seem to be needed

Correct.

I don't know what to do about the service worker feature in main.js

SvelteKit support Service Working auto-registration. But the file itself would need to be rewritten. See https://kit.svelte.dev/docs/service-workers. Generally SW should now all the resource to add preload declaration to the file, so that the tool is PWA and can work offline.

access to the page in the browser is much slower

Here I don't know.

[Blipz]

SvelteKit should work fine with Svelte 3. Generally it's fine, we can improve accessibility later.

Well, these are just warnings, we can also safely ignore them for now.

We need to disable SSR (serve-side rendering) for all Armoria pages. This should ensure that the code is only run in browser and hence no need to check if it has window of not.

Done.

SvelteKit support Service Working auto-registration. But the file itself would need to be rewritten. See https://kit.svelte.dev/docs/service-workers. Generally SW should now all the resource to add preload declaration to the file, so that the tool is PWA and can work offline.

Can I find the original sw.js file somewhere? It might be easier to start from an existing base.

[Azgaar]

Can I find the original sw.js file somewhere? It might be easier to start from an existing base.

Service worked file is generated by generateSW in rollup.config.js.

      generateSW({
        swDest: "./public/sw.js",
        globDirectory: "public/",
        globPatterns: ["**/charges/*.svg"],
        cacheId: "armoria-charges",
        cleanupOutdatedCaches: true,
        inlineWorkboxRuntime: true,
        runtimeCaching: [
          {
            urlPattern: /\.(js|css|html|json)$/,
            handler: "StaleWhileRevalidate",
            options: {
              cacheName: "armoria-app"
            }
          }
        ]
      }),

Basically it adds to cache all charges.

[Azgaar]

import { build, files, timestamp } from '$service-worker';

importScripts('https://storage.googleapis.com/workbox-cdn/releases/6.2.0/workbox-sw.js');

workbox.loadModule('workbox-precaching'); workbox.precaching.precacheAndRoute([...build, ...files]);

[Azgaar]

It should be probably like that one above. It will precache all app files and also all files in static.

Can also install the library to avoid importScripts statement.

import { precacheAndRoute } from 'workbox-precaching';

[Blipz]

Thanks, I'll look into that.