Svelte团队将SvelteKit 3推进至候选发布阶段，核心定位为清理旧代码、为框架长远演进做准备，测试若顺利将配套稳定版本发布，且无破坏性变更。更新重点集中于配置体系重构，Svelte.config.js被移除，配置迁移至vite.config.ts，通过Vite 2.62版本即可实现，正式确认了配置解析流程的优化。争议性变化为别名调整，移除$lib改用#lib，迁移需补充文件扩展名，开发者对此反映存在一致性疑问，但最终明确为积极调整，将纳入package.json原生定义以支持多种场景。同时，配置范式、服务端模块、错误处理、路由机制及底层构建技术等方面均有优化，如tsconfig继承、错误堆栈溯源、浅层路由切换及依赖Vite 8与Rolldown等，整体体现了框架在稳定性与演进方向上的清晰规划。
--91likeyou---
迁移指南建议现有应用使用以下 CLI 命令：
npx sv@next migrate sveltekit-3 --tasks all --confirm复制代码
在 Reddit 上，一位开发者写道，自己讨厌 lib 的这项变化：
我讨厌从 $lib 改成 #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 进行验证。由于 SvelteKit 3 要求使用 Svelte 5，错误处理也得到了改进：+error.svelte 组件会在加载失败和渲染失败时显示，所有错误都会流经 handleError，堆栈跟踪也会获得 Source Map。浅层路由从 pushState 迁移到 goto，并使用 shallow: true 选项。
在底层，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 更小的运行时和响应式语法。
：
🔥 热词：#lib · #Vite · #SvelteKit · #config · #svelte · #js · #foo · #进入