feat: Sveltekit templates

[melMass]

What kind of change does this PR introduce?

• Bugfix
• Feature
• Docs
• New Binding issue #___
• Code style update
• Refactor
• Build-related changes
• Other, please describe:
  • Template

Does this PR introduce a breaking change?

• Yes, and the changes were approved in issue #___
• No

Checklist

• When resolving issues, they are referenced in the PR's title (e.g fix: remove a typo, closes #___, #___)
• A change file is added if any packages will require a version bump due to this PR per the instructions in the readme.
• I have added a convincing reason for adding this feature, if necessary

Other information

This is a WIP that I will finish either today or tomorrow:

• Add the missing rust side (enums etc..) as per this
• Add the Svelte-Kit TS template

Question for Maintainers (cross asked on Discord)

• Can the templates have a splash screen? In the case of Svelte-Kit the approach is a bit different so it might be interesting.. Or it's maybe more suited for an example than a template maybe.

Answered:

No, templates should be kept as simple as possible and all match oob

[amrbashir]

Thank you for your contribution. Please move favicon.png file to the _assets_ folder and include it in the _cta_manifest_ file

[amrbashir]

run pnpm format and cargo fmt --all before commiting

[melMass]

@amrbashir Done the edits, the only thing I find strange is splitting them in the CLI options no? (sveltekit at the end of the list)

[amrbashir]

Templates are always added to the bottom of the list.

[amrbashir]

Thank you

[JDR42]

@melMass This is great to get SvelteKit in the mix, thank you! However, the template might need a fix. Using appWindow throws ReferenceError: window is not defined (when running dev server, i.e., tauri dev).

For example:

//  src/routes/+page.svelte

import { appWindow } from '@tauri-apps/api/window';
...
await appWindow.show();
...

Error:

window is not defined
ReferenceError: window is not defined
    at Object.<anonymous> (D:\Projects\playground\tauri3\node_modules\@tauri-apps\api\window.cjs:1:10927)
    at Module._compile (node:internal/modules/cjs/loader:1126:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1180:10)
    at Module.load (node:internal/modules/cjs/loader:1004:32)
    at Function.Module._load (node:internal/modules/cjs/loader:839:12)
    at ModuleWrap.<anonymous> (node:internal/modules/esm/translators:170:29)
    at ModuleJob.run (node:internal/modules/esm/module_job:193:25)
    at async Promise.all (index 0)
    at async ESMLoader.import (node:internal/modules/esm/loader:533:24)
    at async nodeImport (file:///D:/Projects/playground/tauri3/node_modules/vite/dist/node/chunks/dep-67e7f8ab.js:53137:21)
10:28:27 PM [vite-plugin-svelte] ssr compile done.

This is a known and expected SvelteKit response which happens when SSR is not disabled properly.

So... is SvelteKit's SSR disabled properly in the template? Or perhaps this is a problem with @sveltejs/adapter-static? Is this worth creating an issue for, or must we wait for SvelteKit 1.0?

Again, thank you!

[melMass]

AFAIK this is expected behavior?
Even with SSR off the code is "converted" by svelte compiler.

So I would just move this in onMount

I'm maybe wrong as things moves fast in SK, I contributed this when they announced that there should not be major changes to the API for 1.0

[JDR42]

@melMass I found out that the new way to disable SSR is to add:

export const ssr = false; in /src/routes/+layout.ts

This fixes the issue. The issue and solution are described here.

It seems to me this should be the default behavior in tauri for the sveltekit template. Do you think I should create a PR for this?

[melMass]

@melMass I found out that the new way to disable SSR is to add:

export const ssr = false; in /src/routes/+layout.ts

This was already the case at the time (packages/cli/fragments/fragment-svelte-kit-ts/src/routes/+layout.ts) but maybe they changed the way they are triggered IIRC pre-render induced ssr off. And I use this template in a prod app

Do you think I should create a PR for this?

But yes of course if you think it should be done differently don't hesitate to PR the edit!