Svelte 团队已推动 SvelteKit 3 进入候选发布阶段。这次更新的定位不是堆新功能，而是清理旧代码、为框架未来演进打地基。如果测试顺利，稳定版本随后就会发布，并且不会再有破坏性变更。
换句话说，这是一次"减法"比"加法"更重要的版本。而减法里最扎眼的，是配置位置和别名系统这两刀。
配置从 svelte.config.js 搬到了 vite.config.ts
SvelteKit 2 里的 svelte.config.js 被移除了，配置现在统一放在 vite.config.ts 中。这样改的好处是，Vite 插件能同步读取配置，不必再等一个异步解析步骤——此前这个步骤必须等到完整的 Vite 配置解析完成后才能开始。
参考文档指出，通过 Vite 进行配置早在 2.62 版本中就已引入。所以这次候选版本，更像是对一场已经开始的迁移做出最终确认，而不是突然转向。
争议最大的一刀：$lib 改成 #lib
真正让社区吵起来的是移除 $lib 别名，改用 #lib。后者依赖在 package.json 中声明的 Node 原生子路径导入，而不是使用需要 Vite 和 TypeScript 协同处理的 SvelteKit 专用路径。开发者还需要补上文件扩展名，也就是把 $lib/foo 写成 #lib/foo.js。
迁移指南建议现有应用使用这条 CLI 命令：
npx sv@next migrate sveltekit-3 --tasks all --confirm
在 Reddit 上，一位开发者直言讨厌这个变化：改成 #lib 之后，它和 $app 等其他内容不再一致，希望不要强制使用 #lib，而是允许大家用自己想用的别名。
另一位回复者的态度则来了个急转弯。他起初追问"这背后的逻辑是什么"，随后自己承认这是一项很棒的变化——因为别名被迁移到了 package.json 原生的定义方式，意味着你可以在某些可能需要脱离 SvelteKit 运行的 lib/server 代码里继续使用该别名。
在最初的 GitHub Issue 中，维护者 Rich Harris 坦率谈了权衡。他说自己"很希望所有人都使用 nodenext"，但无扩展名导入可能会让"用户反感"，并补充称，任何反对这一变化的人"始终可以创建自己的别名"。
还有哪些跟着变
除了配置和别名，这一版还动了不少地方：
- tsconfig.json 现在继承 $app/tsconfig，而不是生成的 .svelte-kit 文件
- Service Worker 从 $app/env、$app/paths 和新的 $app/manifest 模块中获取内容
- 显式环境变量结束实验阶段，并可选择使用 Standard Schema 进行验证
- 浅层路由从 pushState 迁移到 goto，并使用 shallow: true 选项
由于 SvelteKit 3 要求使用 Svelte 5，错误处理也得到了改进：+error.svelte 组件会在加载失败和渲染失败时显示，所有错误都会流经 handleError，堆栈跟踪也会获得 Source Map。
底层方面，SvelteKit 3 现在要求使用 Vite 8 及其 Rolldown 打包器，以实现更快的构建。不过团队拒绝采用 FetchableDevEnvironment，理由是它迫使框架承担过多复杂性。
仍然藏在实验性标志之后的，是远程函数——一种类型安全的客户端—服务器 RPC 方法，与 React Server Actions 和 Next.js 服务器函数相呼应。团队表示，相比之下，它让 load 函数和 actions 显得"有些笨拙"。
SvelteKit 是 Svelte 的官方应用框架，构建于 Vite 之上，由目前已加入 Vercel 的 Svelte 团队维护。它负责处理路由、服务器端渲染、数据加载和部署适配器，让开发者能用基于编译器的 Svelte UI 框架构建全栈 Web 应用，而不必依赖虚拟 DOM。
自 2022 年末发布 1.0 版本以来，它已经成为构建 Svelte 应用的默认方式。它将自身定位为 Next.js 和 Remix 等 React 框架的竞争者，同时依托 Svelte 更小的运行时和响应式语法。
热门跟贴