[crowlKats]

Fixes #35531.

Problem

A default SvelteKit app created with deno run -A npm:sv create my-app uses @sveltejs/adapter-auto, which framework detection didn't recognize. Because SvelteKit ships a vite.config and a vite dependency, detection fell through to the generic Vite branch ("Detected Vite framework") and tried to bundle a non-existent dist/ directory — producing the errors in the issue (No such file or directory for dist, and the spurious TS5095/TS5109 type-check errors from the Vite SPA entrypoint graph).

Fix

In cli/tools/framework.rs:

• A svelte.config.* now makes SvelteKit own detection. It can no longer fall through to the generic Vite branch, which was the root cause of the misdetection.
• @sveltejs/adapter-node is now recognized. It emits the same build/index.js server shape as svelte-adapter-deno and runs under Deno via Node.js compatibility, so no Deno-specific adapter is required.
• Unsupported/undetermined adapters now produce an actionable error instead of a confusing Vite mis-detection, with a dedicated hint for adapter-auto (the sv create default), which produces no local server output at all.

Tests

• Added detects_sveltekit_adapter_node_from_config
• Added errors_on_sveltekit_adapter_auto
• Replaced the old "unknown adapter → None" test with errors_on_sveltekit_with_unsupported_adapter (the previous behavior of silently falling through to Vite was the bug)

All SvelteKit detection tests pass; cargo clippy is clean.

[bartlomieju]

Review

The diagnosis is correct and the fix targets the actual root cause — gating Vite behind svelte.config absence and returning detect_sveltekit(dir).map(Some) cleanly eliminates the misdetection. Changing the return type from Option to Result is the right move, adapter-node post-build detection works (it emits both build/index.js and build/handler.js), and #[derive(Debug)] is correctly needed for the new .unwrap().unwrap() in tests.

One issue worth addressing before merge:

Config-extension mismatch now produces a misleading hard error

The entry gate accepts five extensions:

// has_config_file
["js", "mjs", "ts", "mts", "cjs"]

but detect_sveltekit only reads three when inspecting config text:

["svelte.config.js", "svelte.config.ts", "svelte.config.mjs"]
  .iter()
  .find_map(|f| std::fs::read_to_string(dir.join(f)).ok())
  .unwrap_or_default();

So a project with svelte.config.mts or svelte.config.cjs — even one correctly configured with @sveltejs/adapter-node — passes the gate, reads an empty string via unwrap_or_default(), matches no adapter branch, and now bails with "no adapter that deno desktop can bundle is configured."

This mismatch pre-existed, but the old code returned None (silently falling through), so it was latent. This PR promotes it to a hard, actively-wrong error telling users their valid adapter isn't supported. Since sv create + an immediate deno desktop is exactly the reported flow, this is reachable. Suggest aligning the read list with has_config_file (add mts/cjs), ideally factored so the two can't drift again, plus a svelte.config.mts + adapter-node test.

Minor

• The bail message hardcodes svelte.config.js ("Configure a supported adapter in svelte.config.js") — slightly off for .ts/.mts users.
• Unsupported adapters now propagate Err from detect_framework rather than Ok(None). This is the intended trade-off, just worth confirming the top-level command renders it as a clean message rather than a hard failure for adapter-vercel/adapter-cloudflare users.

Tests are good — replacing the old "unknown adapter → None" test was the right call since that behavior was the bug. Otherwise approve-worthy.

[bartlomieju]

adapter-static SvelteKit projects now hit the bail! path, they have @sveltejs/kit, pass the gate, but produce no build/index.js server output, so they fall into the "no adapter that deno desktop can bundle" error. That's arguably correct for a tool that bundles a server binary (a static-only site has no server to run), and the error is actionable. But it's a behavior change from the old silent None, and adapter-static is a common, legitimate SvelteKit setup. Two options worth a moment's thought:

• Leave as-is (a static site genuinely has no server entrypoint for deno desktop), or
• Give adapter-static its own tailored hint in the bail message, the way adapter-auto gets one — since "configure adapter-node" isn't necessarily the right advice for someone who deliberately wants a static build.

We can address it in a follow up though

[MattheousDT]

This currently doesn't work with newly initialised sveltekit projects as sv create puts the svelte config entirely inside of the vite.config.* and doesn't create a svelte.config.*

Output of using npx sv@latest create using the node adapter option

├── deno.lock
├── node_modules
├── package.json
├── README.md
├── src
├── static
├── tsconfig.json
└── vite.config.ts

vite.config.ts

import adapter from '@sveltejs/adapter-node';
import { sveltekit } from '@sveltejs/kit/vite';
import { defineConfig } from 'vite';

export default defineConfig({
	plugins: [
		sveltekit({
			compilerOptions: {
				// Force runes mode for the project, except for libraries. Can be removed in svelte 6.
				runes: ({ filename }) =>
					filename.split(/[/\\]/).includes('node_modules') ? undefined : true,
				experimental: { async: true }
			},
			adapter: adapter(),
			experimental: { remoteFunctions: true, handleRenderingErrors: true }
		})
	]
});

Running deno desktop . just recognises it as a vite project

[mustofa-id]

This currently doesn't work with newly initialised sveltekit projects

workaround:

adapter: adapter({ out: "dist" })