后端前端【免费下载链接】sapperThe next small thing in web development, powered by Svelte项目地址https://gitcode.com/gh_mirrors/sa/sapper点击查看免费下载Sapper 框架在开发阶段通过sapper dev提供带热重载的开发服务器但当应用需要上线时我们需要一份自包含、经过优化的生产构建产物。本文围绕 Sapper 官方文档 09-building.md 展开系统讲解sapper build命令的用法、构建产物结构、底层构建流水线以及 Rollup 场景下通过--legacy标志为旧浏览器生成第二份兼容 bundle 的完整原理。读完本文你将掌握如何一键产出可部署的 Node 应用并能自主决定是否为 IE 等旧浏览器构建兼容版本。从sapper dev到生产构建在之前的开发流程中我们一直使用sapper dev来构建应用并启动开发服务器。它在 src/cli.ts 中定义支持-p/--port、--open、--hot、--live、--bundler、--ext等选项并在监听文件变化时自动重新构建。然而sapper dev面向的是开发体验构建产物未经压缩优化、构建过程反复触发、输出路径默认指向__sapper__/dev。当应用要正式部署时我们需要的是一次性、自包含、优化过的生产构建——这正是sapper build的职责。sapper build一行命令产出生产构建sapper build会把整个应用打包进__sapper__/build目录。命令定义位于 src/cli.ts支持通过位置参数指定目标目录并提供了丰富的选项sapper build [dest]其中dest默认为__sapper__/build其余选项及其默认值如下选项说明默认值-p, --port应用监听端口默认取process.env.PORT3000--bundler指定打包器rollup或webpack留空则自动检测auto--legacy额外创建一份旧浏览器专用的构建关闭--cwd当前工作目录.--src源码目录src--routes路由目录src/routes--outputSapper 中间文件输出目录src/node_modules/sapper--ext自定义页面路由扩展名空格分隔.svelte .html官方文档特别提醒所有选项都可以通过sapper build --help查看。例如要把构建输出到自定义目录并改端口可以这样写sapper build custom-dir -p 4567构建完成后__sapper__/build是一份标准的 Node 应用可以直接从项目根目录运行node __sapper__/build构建产物里到底有什么运行sapper build后__sapper__/build目录主要包含以下内容index.js启动器由构建命令在收尾阶段自动生成见 src/cli.ts内容大致如下// generated by sapper build at 时间戳 process.env.NODE_ENV process.env.NODE_ENV || production; process.env.PORT process.env.PORT || 3000; require(./server/server.js);它负责设置NODE_ENV与PORT环境变量未显式设置时回退到构建时指定的端口或 3000然后加载编译后的服务端代码。node __sapper__/build实际运行的就是这个入口。client/客户端 bundle 输出目录按[name].[hash].js命名并带 sourcemap使用--legacy时额外生成client/legacy/子目录。server/服务端渲染代码server.js格式取决于是否启用 ESM 模块。service-worker.js由src/service-worker.js编译而来的 Service Worker若项目存在该文件。template.html从src/template.html读取并经过 minify_html 压缩后的 HTML 模板。build.json构建元信息client 资源清单、legacy 资源映射、shimport 版本等供运行时按需分发资源。shimportversion.js用于不支持原生 ES module 的浏览器回退加载详见下文。构建流水线源码级剖析src/api/build.ts中的build函数完整实现了生产构建的流程src/api/build.ts大致分为以下阶段参数归一化把cwd、src、routes、dest、output、static全部解析为绝对路径若legacy与webpack同时出现直接抛出Legacy builds are not supported for projects using webpack错误。清理与初始化清空中间输出目录src/node_modules/sapper与目标目录dest拷贝 Sapper 运行时copy_runtime与 shimportcopy_shimport。模板处理读取src/template.html并压缩后写入dest/template.html。生成 manifest通过 create_manifest_data 扫描src/routes生成路由清单再调用 create_app 生成src/node_modules/sapper/app.mjs与server.mjs等中间文件。创建编译器调用 create_compilers 按--bundler选择 Rollup 或 Webpack 编译器分别编译client、server若存在service-worker.js则再编译serviceworker。写入构建信息把客户端编译结果序列化为build.json若启用--legacy则在其中额外记录legacy_assets映射。构建期间src/cli.ts 会实时打印每个编译目标client、server、serviceworker的 banner、警告数量与打包统计信息出现错误则输出带文件与行号的诊断并以非零码退出。--legacy为旧浏览器生成第二份 bundleSapper 默认只为最新版本的现代常青浏览器构建bundle 采用 ES modules 输出并依赖async/await等较新语法。如果项目使用 Rollup可以加上--legacy标志让 Sapper 额外构建一份兼容旧浏览器如 Internet Explorer的 bundle并在运行时按浏览器能力自动分发正确的版本。双份构建与SAPPER_LEGACY_BUILD环境变量使用--legacy时Sapper 会向你的 Rollup 配置传入环境变量SAPPER_LEGACY_BUILD然后分两次构建客户端 bundle第一次SAPPER_LEGACY_BUILD未设置false产出标准现代 bundle第二次SAPPER_LEGACY_BUILD置为true产出 legacy bundle。这一逻辑在 src/api/build.ts 中实现构建前设置process.env.SAPPER_LEGACY_BUILD true重新创建并编译客户端编译器随后删除该环境变量。legacy 编译结果被写入build_info.legacy_assets最终固化在build.json中。对应的官方 Rollup 配置模板 src/config/rollup.ts 会根据环境变量切换客户端输出目录client: { output: () { let dir ${dest}/client; if (process.env.SAPPER_LEGACY_BUILD) dir /legacy; return { dir, entryFileNames: [name].[hash].js, format: esm, sourcemap }; } }也就是说legacy bundle 会落在__sapper__/build/client/legacy/下与标准 bundle 平级共存。在 Rollup 配置里消费该环境变量以本仓库自身站点为例site/rollup.config.js 首先读取环境变量const legacy !!process.env.SAPPER_LEGACY_BUILD;随后仅在legacy为真时引入 Babel 插件把现代语法转译到目标浏览器可运行的版本site/rollup.config.jslegacy babel({ extensions: [.js, .mjs, .html, .svelte], babelHelpers: runtime, exclude: [node_modules/babel/**], presets: [[babel/preset-env, { targets: 0.25%, not dead }]], plugins: [ babel/plugin-syntax-dynamic-import, [babel/plugin-transform-runtime, { useESModules: true }] ] })这就是官方文档中sapper-template-rollup提供了利用该配置的示例的仓库内对应实现——你可以把site/rollup.config.js当作可复制、可运行的参照模板。运行时按浏览器能力分发构建只是产出了两份 bundle真正选对 bundle的逻辑发生在服务端渲染阶段。在 runtime/src/server/middleware/get_page_handler.ts 中Sapper 向 HTML 注入一段能力探测脚本先用eval(async function x(){})探测浏览器是否支持async/await语法不支持async/await的浏览器将加载 legacy bundle对应文档脚注 2再用new Function(if(0)import())()探测原生 ES module 支持不支持的浏览器回退到 shimport 加载器。因此build.json中的legacy_assets映射是运行时分发 legacy 资源的关键依据——Sapper 在真实请求时才会把正确版本的脚本地址写入响应页面用户全程无感知。实战把构建写进package.json日常开发中不应每次手敲完整命令官方文档建议把--legacy固化到脚本里package.json 与 site/package.json 也展示了这一模式{ scripts: { build: sapper build --legacy } }之后只需npm run build即可完成带兼容构建的生产打包。若项目使用 Webpack请注意两点限制从 src/api/build.ts 的源码可见--legacy与webpack不兼容会直接报错不启用--legacy时webpack 构建的客户端 bundle 走的是script src...普通脚本加载路径见 get_page_handler.ts而非 ES module shimport 的组合。注意事项--legacy与 Svelte 的legacy选项无关Svelte 编译器自身也有legacy选项用于处理 Svelte 编译产物的旧语法兼容二者是相互独立的机制文档脚注 1 明确指出了这一点。仍需 polyfill 缺失 APIlegacy bundle 只解决了语法层面的兼容通过 Babel 转译像fetch、Promise等旧浏览器缺失的 API 并不会自动补齐需要在应用中自行引入 polyfill文档脚注 3。此外官方文档声明 Sapper 已停止维护新项目应迁移到 SvelteKit参考 site/content/docs/00-introduction.md 的说明与仓库内 migrating 指南。部署前自检构建完成后先本地执行node __sapper__/build验证启动、再决定托管方式如果需要纯静态导出而非 Node 部署可参考仓库内的 10-exporting.md其中sapper export同样支持--legacy见 site/package.json 的export: sapper export --legacy用法。小结Sapper build把开发态的 Sapper 应用收敛为一份可直接node运行的自包含生产产物内部则是一套清晰的流水线清场拷贝 → 模板压缩 → manifest 生成 → 三端编译client/server/serviceworker→ 元信息落盘。而--legacy则通过SAPPER_LEGACY_BUILD环境变量驱动 Rollup 双份构建配合服务端渲染阶段的运行时能力探测与build.json资源映射让同一份代码同时服务现代浏览器与 IE 等旧环境。理解这两点你的 Sapper 应用就具备了完整、可控的生产发布能力。赞分享后端前端【免费下载链接】sapperThe next small thing in web development, powered by Svelte项目地址https://gitcode.com/gh_mirrors/sa/sapper点击查看免费下载相关推荐昇腾NPU上的YOLOv5故障排除手册20个常见问题与解决方案汇总昇腾NPU上的YOLOv5故障排除手册20个常见问题与解决方案汇总 在昇腾NPU上部署和运行YOLOv5目标检测模型时开发者经常会遇到各种环境配置、训Hatch 构建Builds完全指南从 build 配置、构建命令到打包生态兼容Hatch 构建Builds完全指南从 build 配置、构建命令到打包生态兼容 本篇指南以 Hatch 项目的 docs/build.md 与 docs操作系统嵌入式RTOS物联网Sapper服务端路由终极指南10分钟构建RESTful API接口Sapper服务端路由终极指南10分钟构建RESTful API接口 Sapper是基于Svelte的下一代Web开发框架专为构建高性能的服务端渲染应用而生后端前端创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考