SvelteKit 3 进入 RC：svelte.config.js 没了，$lib 也要退休
点击查看原文>
Svelte 团队已推动 SvelteKit 3 进入候选发布阶段，并将此次更新定位为清理旧代码、为框架未来演进奠定基础的机会，而不是一次包含大量新功能的发布。如果测试顺利，预计随后将发布稳定版本，且不会再有破坏性变更。
最主要的变化是配置位置。SvelteKit 2 中的 svelte.config.js 已被移除，配置现在位于 vite.config.ts 中，使 Vite 插件能够同步读取配置，而不必等待异步解析步骤；此前，该步骤必须等到完整的 Vite 配置解析完成后才能开始。参考文档指出，通过 Vite 进行配置早在 2.62 版本中就已引入，因此此次候选版本是对已经开始的迁移过程作出最终确认。
争议最大的一项变化是移除 $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 的这项变化：
我讨厌从
$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 更小的运行时和响应式语法。
本文来源：InfoQ