对 Sapper 的更新,以实现更流畅的转换到 SvelteKit

Sapper 开发已经结束,但 SvelteKit & Vite 尚未稳定,目前还不适合一些项目,尤其是 SSR 问题 (https://GitHub.com/vitejs/vite/discussions/4230)。 任何经历过大型项目迁移的人都会告诉你,意想不到的边缘情况经常会出现。 SvelteKit 迁移成功的隐藏下游技术风险也很大。这通常发生在难以为迁移优先考虑而与客户项目需求取得平衡的情况下。 与此同时,一些 Sapper 项目正在等待 SvelteKit 成熟到可以将迁移风险降到最低的程度。 由于需要 SPA 支持,而 Sapper 不能提供此支持 (https://GitHub.com/sveltejs/sapper/issues/383),我就采取了迁移到 SvelteKit 的步骤,包括将所有依赖库转换为 `"type": "module"",以及在 https://kit.svelte.dev/migrating 中建议的其他更改。 现在,由于遇到了 SSR 问题,包括 https://GitHub.com/sveltejs/kit/issues/1947,我意识到 Sapper 不支持 ES 模块,并且与 SvelteKit 的 API 不同。如果 Sapper 可以被改造以支持 SvelteKit 的一些配置和 API,那么未来的迁移将更容易,迁移过程也可以降低风险,因为可以让失败的迁移回退到 Sapper。 这些更改应该是微小的,例如允许 `rollup.config.mjs` 支持 ES 模块 (https://GitHub.com/sveltejs/sapper/issues/1204)。另外一个好处是支持与 SvelteKit 具有相同 API 的 `load` 函数(一个替代 `preload` 的函数)。其他兼容的 SvelteKit 更新也可以回移。 Sapper 独特 API 的淘汰以及与 SvelteKit 行为的兼容性也可能有助于鼓励现有 Sapper 项目考虑并迁移到 SvelteKit。