[1.x] Add SSR support for Svelte 5

[pedroborges]

The primary goal for this PR is to maintain Svelte 4 as the default version in the adapter, ensuring stability for existing projects. However, I've also added support for Svelte 5, taking advantage of its backward compatibility with Svelte 4. This allows developers to upgrade their projects to Svelte 5 without needing to modify the adapter or deal with any breaking changes.

TL;DR:
The adapter remains on Svelte 4, but you can use either Svelte 4 or Svelte 5 in your projects seamlessly.

In Svelte 5 users no longer need to explicitly enable client side hydration in their vite.config.js file:

+     svelte(),
-     svelte({
-       compilerOptions: {
-         hydratable: true,
-       },
-     }),

[pedroborges]

@jamesst20, please help us test this PR if you can spare a moment 😉

[pedroborges]

Needed to preserve the /* @vite-ignore */ comment that prevents Vite from statically analyzing and bundling svelte/server.

[pedroborges]

Svelte 3.59.2, the latest version 3, was released over a year ago. We should consider whether it's worth continuing support for it. As far as I know, it still works with the current Svelte adapter, but with the upcoming v2.0 features and Svelte 5 on the horizon, we don't have the capacity to test across all versions to ensure full compatibility.

[pedroborges]

Since this PR will be merged into Inertia 1.3, we'll maintain support for Svelte 3 for now and drop it with the release of Inertia V2.

[jamesst20]

@jamesst20, please help us test this PR if you can spare a moment 😉

Appears to be fine on my end! The approach of checking the Svelte version at runtime is the first approach I had taken in the past but for some reason it failed to work because the detected version at runtime was the one @inertiajs/svelte was built with instead of the version being used in the playground. I wonder where I failed. Not sure if this is the right commit in the history but it looked like this jamesst20@db54015#diff-ee8bc50b28e24eefd929600798a4a4c3283bd349a8bd968b0bef56c08271f628R7

I had opened a stackoverflow about it but couldn't find any solution at the time https://stackoverflow.com/questions/78470116/are-dynamic-imports-at-runtime-in-the-browser-esm-possible-with-svelte

It appears your implementation works as expected which is nice !

Edit

It appears the reason your way works and not mine is because Vite can't guess what the imported package is because you're doing it like this:

async function dynamicImport(modulePath: string) {
  try {
    return await import(/* @vite-ignore */ modulePath)
  } catch {
    return null
  }
}

but if it were like this you would end up having the same kind of issue I had

async function dynamicImport() {
  try {
    return await import(/* @vite-ignore */ 'svelte/server')
  } catch {
    return null
  }
}

[pedroborges]

Thank you for testing it out, @jamesst20! Yes, passing the module path to dynamicImport was intentional—it was necessary after several failed attempts.

[jamesst20]

Thank you for testing it out, @jamesst20! Yes, passing the module path to dynamicImport was intentional—it was necessary after several failed attempts.

Yeah this is crazy the right idea was there I just couldn't get it to work and yet it was so simple.

I wonder here jamesst20@b9a902d#diff-ee8bc50b28e24eefd929600798a4a4c3283bd349a8bd968b0bef56c08271f628R50 if I had changed

const { render } = await import('svelte/server')
return render(SSR, { props: { id, initialPage } })

to

const svelteImport = 'svelte/server'
const { render } = await import(svelteImport)
return render(SSR, { props: { id, initialPage } })

if this would also have worked. Anyway this is good news as breaking changes that relates to Inertia can be completely avoided

[jamesst20]

Out of subject a little bit because I can see there are build errors. I had some troubles as well and was forced to move from NPM to PNPM at some point. I am not sure if this is what is happening here. From my testing I realized that when using NPM, the specified version in the packages.json from each "workspace" were not necessary always respected. I also realized that some of these workspaces were depending on some dependencies that were not explicitly declared in the packages.json but because some other project in the workspace were using them directly or indirectly from a subdepedency, it worked. If you are ever interested in taking a look, I had a PR opened to migrate to PNPM. Unfortunatly that PR was based on top of another one which updated every packages (#1874) but the relevent files are {packages,playgrounds}/**/package.json and pnpm-workspace.yaml and .npmrc and the github workflow itself. https://github.com/inertiajs/inertia/pull/1875/files#diff-0b810c38f3c138a3d5e44854edefd5eb966617ca84e62f06511f60acc40546c7

This had received 0 attention but I still think it was worth something #1873

[pedroborges]

Necessary because I got a ReferenceError: [plugin vite-plugin-svelte] structuredClone is not defined error on the build workflow while building the Svelte 5 playground.