Converting a Rollup-based Svelte SPA to SvelteKit

[dummdidumm]

I just converted a small to medium sized application based on Rollup and third-party router to SvelteKit. I'm putting some notes in here for those who are interested in the conversion process:

• The project uses tsyringe, a dependency injection library. Rollup supports emitDecoratorMetadata, SvelteKit which uses Vite which uses ESBuild doesn't. Luckily it still works if you add explicit @inject(ClassToInject) in from of every contructor injection. You still need to provide some library for Reflect.getMetadata to exist else tsyringe errors out, there's an open issue requesting to change that
• The proejct used svelte-spa-router previously. Conversion to SvelteKit's file-based routing was straightforward. use:link just became unnecessary, replace became goto
• The project uses Tailwind V2. The config file was renamed to end with .cjs since it's written with CommonJS syntax.
• The rollup.config.js was removed, it didn't have anything special in there excpect path aliases. These were moved to kit.vite.resolve.alias without problems. There was one usage of the Rollup replace plugin to use environment-specific variables, which was easy to move into the alias array (no .env file usage in this project). The alias needed __dirname to exist which isn't the case in ESM so it's created "manually". The folder that needed to be deployed was public, and to not change that, I adjusted the adapter-static-setting for that. The svelte.config.js now looks like this:

import adapter from "@sveltejs/adapter-static";
import preprocess from "svelte-preprocess";
import path from "path";
import { fileURLToPath } from "url";

const __filename = fileURLToPath(import.meta.url);
const __dirname = path.dirname(__filename);

const projectRootDir = `${__dirname}/src`;

/** @type {import('@sveltejs/kit').Config} */
const config = {
  preprocess: preprocess(),

  kit: {
    prerender: { enabled: false },
    adapter: adapter({ pages: "public", fallback: "index.html" }),
    vite: {
      resolve: {
        alias: [
          {
            find: "environments/environment",
            replacement: `${projectRootDir}/environments/${
              process.env.NODE_ENV === "prod"
                ? "environment.prod"
                : process.env.NODE_ENV === "stage"
                ? "environment.stage"
                : "environment"
            }`,
          },
          // If you add a new top-level-folder below src, add them here
          { find: /^components(\/|$)/, replacement: `${projectRootDir}/components/` },
          { find: /^services(\/|$)/, replacement: `${projectRootDir}/services/` },
          { find: /^api(\/|$)/, replacement: `${projectRootDir}/api/` },
          { find: /^model(\/|$)/, replacement: `${projectRootDir}/model/` },
          { find: /^utils(\/|$)/, replacement: `${projectRootDir}/utils/` },
        ],
      },
    },
  },
};

export default config;

• The tsconfig.json is the one from SvelteKit with some minor enhancements:

{
  "extends": "./.svelte-kit/tsconfig.json",
  "compilerOptions": {
    "strict": true,
    "experimentalDecorators": true,
    "baseUrl": "src"
  }
}

• To skip SSR completely I added a hooks.ts with the following:

import type { Handle } from "@sveltejs/kit";

// Following config makes sure we never do server side rendering and are a simple SPA instead
export const handle: Handle = async ({ event, resolve }) => {
  const response = await resolve(event, {
    ssr: false,
  });
  return response;
};

• The assets were stored in public, I just moved them over to assets where SvelteKit expects these to appear. I merged the old index.html into the app.html. After that, there wasn't anything left in public that was necessary so I deleted it and put it in .gitignore, it became the build output (also see svelte.config.js)

Overall this was a nice experience and was easier than I thought. Hope this helps someone!

[jtlapp]

I'm hoping to convert an SPA (back) to svelte-kit in a few months, so this will be helpful, but I'll also need to address other problems. Does your solution happen to do any of the following?

• Put the svelte-kit solution in a package within a monorepo?
• Run jest or mocha tests on backend code used by svelte-kit APIs, sans DOM?
• Have separate CLI tools that use the same backend code?

[dummdidumm]

I'm afraid no. The backend is written in Java and they don't share any tooling/test setup.