SvelteKit 究竟是什么？

如果你上个月参加了 Svelte Summit，你可能看过我的演讲”未来主义网络开发”，我终于回答了关于 Svelte 最常被问到的问题之一：Sapper 什么时候会发布 1.0 版本？

答案是：永远不会。

这句话有点开玩笑的意味 — 正如演讲中解释的那样，这实际上更像是对 Sapper 的重写加上品牌重塑 — 但这引发了社区的许多新问题，现在是时候就 Sapper 的继任者 SvelteKit 为大家提供更多清晰的说明了。

Sapper 是什么？

Sapper 是建立在 Svelte（一个组件框架）之上的应用框架（或称”元框架”）。它的工作是让使用现代最佳实践（如服务器端渲染（SSR）和代码分割）构建 Svelte 应用变得容易，并提供一个使开发高效且有趣的项目结构。它使用基于文件系统的路由（由 Next 普及，并被许多其他框架采用，尽管有一些增强功能）— 你的项目文件结构反映了应用本身的结构。

虽然 Svelte 主页和文档鼓励你使用 degit 克隆 sveltejs/template 仓库来开始构建应用，但 Sapper 一直是我们推荐的构建应用的方式；这篇博文本身（在写作时！）就是用 Sapper 渲染的。

为什么我们要迁移到新的框架？

首先，sveltejs/template 和 sveltejs/sapper-template 之间的区别令人困惑，特别是对 Svelte 的新手来说。有一个统一的推荐方式来开始构建 Svelte 应用将带来巨大的好处：我们简化入门过程，减少维护和支持负担，并且可能开始探索由可预测的项目结构所带来的新可能性。（最后这部分故意说得比较模糊，因为需要时间才能完全理解这些可能性是什么。）

除此之外，我们一直被重写 Sapper 的想法所吸引。部分原因是因为代码库多年来变得有点杂乱（Sapper 始于 2017 年），但主要是因为 Web 最近发生了很大变化，是时候重新思考我们的一些基本假设了。

这个新东西有什么不同？

第一个基本假设是，你需要使用像 webpack 或 Rollup 这样的模块打包工具来构建应用。这些工具会追踪应用的依赖图，在此过程中分析和转换代码（例如，将 Svelte 组件转换成 JS 模块），以便生成可以在任何地方运行的代码包。作为 Rollup 的原始创作者，我可以证明这是一个出人意料地复杂的问题，包含一些极为棘手的边缘情况。

几年前，浏览器本身不支持 import 关键字，所以你确实需要一个打包工具，但在今天，这种需求已经大幅减少。现在，我们看到了无打包开发工作流的兴起，这种方式特别简单：不再急于打包你的应用，一个开发服务器可以按需提供模块（如果必要时将其转换成 JavaScript），无论你的应用多大，启动几乎都可以瞬间完成。

Snowpack 是这一趋势的先锋力量，也是 SvelteKit 的驱动核心。它的速度极为惊人，并提供了优雅的开发体验（包括热模块重载、错误覆盖等）。我们还与 Snowpack 团队密切合作，开发了诸如 SSR 之类的功能。对于那些习惯于使用 Rollup 的 Sapper 用户来说，热模块重载功能尤其具有革命性意义（由于 Sapper 的架构，Rollup 从未具备一流的 HMR 支持，因为它优先考虑最有效的输出）。

这并不是说我们完全放弃了打包工具。为了优化你的应用以供生产使用，它仍然是必不可少的，SvelteKit 使用 Rollup 来让你的应用尽可能快速和轻量化（包括将样式提取到静态 .css 文件中）。

另一个基本假设是，一个服务器渲染的应用需要一个服务器。Sapper 实际上有两种模式——sapper build 会创建一个必须运行在 Node 服务器上的独立应用，而 sapper export 则会将你的应用制作成一组静态文件，适合托管在像 GitHub Pages 这样的服务上。

静态文件几乎可以放在任何地方，但运行一个 Node 服务器（以及监控/扩展它等）就没那么容易了。现在，我们正在见证向无服务器平台的转变，在这种平台中，作为应用作者的你无需考虑代码运行的服务器，以及由此带来的所有复杂性。通过类似 vercel-sapper 的工具，你可以让 Sapper 应用运行在无服务器平台上，但这显然称不上是惯用模式。

SvelteKit 完全拥抱了无服务器模式，并将为所有主要的无服务器提供商提供支持，同时还会提供一个 “适配器” API，用于支持那些我们官方未覆盖的平台。此外，我们将支持部分预渲染，这意味着静态页面可以在构建时生成，而动态页面将在请求时渲染。

我什么时候可以开始使用？

如果你愿意冒风险，现在就可以开始：

npm init svelte@next

这将生成一个新项目并安装 @sveltejs/kit CLI，后者提供开发和构建应用所需的工具。

不过，我们并不推荐现在就使用！目前没有文档，我们也无法提供任何形式的支持。而且它也会经常出问题。

当前的开发工作正在一个私有的 Monorepo 中完成，因为我们仍处于探索阶段。我们的计划是准备一个公开的测试版，并在这里宣布，当我们解决了一些问题后，代码库本身仍将保持私有，但我们会创建一个地方来收集 YOLO 用户的反馈。在那之后，我们将努力推出 1.0 正式版，其中包括开源代码库。

我不想对时间做出任何明确的承诺，因为我不喜欢违背承诺。但我认为我们谈论的是数周，而不是数月。

如果我不想使用 SvelteKit 怎么办？

你不必使用它——Svelte 仍然可以以独立包的形式使用，或者通过像 rollup-plugin-svelte 这样的打包工具集成。我们认为让你能够根据自己的工作流（无论多么特别）来使用 Svelte 并与诸如 Elder.js、Routify、Plenti、Crown、JungleJS 等第三方应用框架配合是至关重要的。

TypeScript 支持如何？

别担心，在没有完全支持 TypeScript 的情况下我们不会发布。

我怎样迁移现有的 Sapper 应用？

大多数情况下，迁移 Sapper 代码库应该相当简单。

有一些不可避免的变化（运行在无服务器平台上意味着我们需要用更便携的替代方案替换自定义的 server.js 文件和 (req, res) => {...} 函数），我们也借此机会修复了一些设计缺陷，但总体而言，SvelteKit 应用对 Sapper 用户来说会非常熟悉。

在 1.0 发布时会有详细的迁移指南。

我能如何贡献？

留意我们关于何时推出公开测试版并开放代码库的公告。（此外，博客文章 TODO，但我不得不提一下，我们现在有了一个 OpenCollective，如果这个项目对你有所帮助，可以通过这个途径做出经济支持。对于那些已经做出贡献的朋友，我们深表感谢。）

哪里可以了解更多？

关注 Twitter 上的 @sveltejs 和 @SvelteSociety，以及访问 svelte.dev/chat。你也可以订阅 Svelte Radio，Kevin 和他的主持人会在即将到来的一期节目中对我进行关于这个项目的采访（在我们录制之前的这周里，可以回复这一条 Twitter 线，提出你的其他问题）。