Meteor 现代构建工具链维护指南SWC、Rspack 与 Profiler 的架构与集成【免费下载链接】meteorMeteor, the JavaScript App Platform项目地址: https://gitcode.com/gh_mirrors/me/meteorMeteor 的现代工具链围绕三大支柱构建SWC基于 Rust 的转译器/压缩器、Rspack兼容 Webpack 的打包器集成与Profiler性能分析工具并通过tools-core辅助包为所有现代集成提供共享能力。本文是面向维护者Maintainer的架构总览与操作手册读者将掌握这三大组件如何通过构建插件接入 Meteor 的打包生命周期、各自在仓库中的落点与职责边界、E2E 测试覆盖矩阵以及升级依赖、发布包、排查性能问题等高频维护任务的完整流程。若你是最终用户而非维护者请直接参阅用户向文档 Modern Build Stack User Guide。Integration Architecture外部工具如何接入 Meteor 构建生命周期外部工具通过各自package.js中声明的构建插件build plugin接入 Meteor 的打包生命周期。Meteor 提供两个主要的集成点详见 dev/modern-tools/README.mdPackage.registerBuildPlugin—— 用于在打包器运行之前派生外部进程或配置 Meteor。示例Rspack 用它初始化开发服务器与构建上下文。Package.registerBuildPlugin({ name, sources, use });Plugin.registerCompiler—— 用于在构建过程中处理特定源文件。示例TypeScript 与 Babel 集成用它编译各自负责的文件。Plugin.registerCompiler({ extensions, filenames }, factory);设计原则工具集成被限定在其各自的 Atmosphere 包作用域内。执行meteor add rspack即接入该工具移除它则完全清理干净Meteor 核心工具对这些外部工具保持零硬编码引用。这一原则在源码中有直接印证packages/rspack/package.js中正是通过Package.registerBuildPlugin注册了名为rspack的构建插件并在Package.onUse中以api.use([tools-core, webapp])声明运行时依赖见 packages/rspack/package.js。核心 Meteor 工具无需感知 Rspack 的存在一切接线都发生在包自身内部。Thetools-coreHelpers Package现代集成的公共底座packages/tools-core是一个devOnly的 Meteor 包见 packages/tools-core/package.js为 npm 管理、进程处理、日志与配置提供共享工具。它的设计初衷是让 Rspack、CapacitorJS 这类现代集成复用同一套能力避免重复造轮子。包入口 packages/tools-core/tools-core.js 以export *形式统一导出lib/下各模块。核心模块总览模块职责lib/log.js日志提供彩色、一致的声明周期日志logProgress、logSuccess等并尊重METEOR_DISABLE_COLORS环境变量lib/npm.js依赖处理 npm/yarn 校验与安装使用installNpmDependency、getNodeBinaryPath等辅助函数可靠地操作项目依赖lib/process.js进程暴露spawnProcess管理子进程自带健壮的默认行为保留颜色、优雅终止、端口协调lib/meteor.js内省读取用户配置、检测项目特征如isMeteorAppTest、isMeteorBlazeProject并通过setMeteorAppEntrypoints动态管理入口点lib/global-state.js状态通过Package.meteor.global.persistentState在增量重建之间管理状态lib/git.js与lib/ignore.js文件系统自动更新.gitignore管理复杂的文件监听器排除规则完整的模块文档见 packages/tools-core/README.md。该包还附带基于 Tinytest 的测试tests/meteor_tests.js、tests/global_state_tests.js在package.js的Package.onTest中注册保证状态管理与项目内省逻辑的稳定性。SWC Transpiler IntegrationRust 级转译与压缩SWC 是 Meteor 现代构建路径上的转译器与压缩器。核心打包器为 packages 使用meteorjs/swc-core而应用级代码经由 Rspack 的swc-loader处理。维护者指南位于 dev/modern-tools/swc/README.md。为何引入 SWCSWC 的目标是在现代路径上取代 Babel 转译步骤将转译从 Babel 迁移到基于 Rust 的解析器/代码生成器上显著加速冷构建与重建在不要求用户维护 Babel 配置的前提下完整保留 Meteor 特有行为reify 模块、嵌套导入、顶层 await、modern/legacy 浏览器目标让转译器编译步骤与压缩器生产构建复用同一个 SWC 后端打包器无需同时携带两套 JavaScript 引擎。SWC 在代码库中的三个落点packages/babel-compiler—— 转译入口。依赖meteorjs/swc-core见package.js。babel-compiler.js暴露compileWithSwc(source, swcOptions, { features })输出由meteorjs/reify后处理使模块编译、嵌套导入、顶层 await 与 modern/legacy 目标的行为与 Babel 一致。initializeMeteorAppSwcrc按.swcrc→swc.config.js→swc.config.ts的顺序解析用户 SWC 配置动态.js/.ts配置会被读取、用 SWC 自身转译为 CJS 后求值解析结果按「文件 mtime 内容哈希」缓存。BabelCompiler导出SwcCompiler变体当 modern 模式启用Meteor.modern: true或METEOR_MODERN时生效SWC 无法处理的文件会回退到 Babel并在 verbose 模式下打印[Transpiler] Used SWC/Used Babel行。packages/standard-minifier-js—— 压缩入口。依赖meteorjs/swc-coreplugin/minify-js.js惰性加载它作为现代构建目标的压缩器。npm-packages/meteor-rspack—— 打包器侧集成。bundler 使用 Rspack 的swc-loaderpeer 依赖swc/core见package.json的peerDependencieslib/swc.js为 loader 解析同一族.swcrc/swc.config.js/swc.config.ts配置lib/localDependenciesHelpers.js用swc/core解析用户的rspack.config.js以发现应使持久缓存失效的本地插件文件。swc/core与meteorjs/swc-core的区别升级版本时必须分清这两个包meteorjs/swc-core是 Meteor 控制的包装包内置vendored了swc/core及其原生二进制。它声明在babel-compiler/package.js与standard-minifier-js/package.js中。内置机制让 Meteor 能为每个受支持平台分发正确的原生二进制不依赖各用户 npm 安装时的 optional-dependency 平台选择逻辑同时锁定了 Meteor 工具所构建的 SWC API。swc/core是上游包作为meteorjs/rspack的 peer 依赖存在——swc-loader会从用户项目解析它。用户应用经由 Rspack 集成rspackAtmosphere 包的自动安装流程安装它。bundler 集成也在meteor-rspack/lib/swc.js与lib/localDependenciesHelpers.js中直接require(swc/core)解析用户配置该版本由项目级安装控制而非meteorjs/swc-core。简言之工具侧编译/压缩路径使用meteorjs/swc-corebundler 侧 loader 路径使用swc/core二者应同步推进使用户应用与工具在语法支持上保持一致。调试要点设置METEOR_PROFILE1在报告中查找SWC.compile/Babel.compile条目确认每个文件走了哪条路径在package.json中设置meteor.modern.verbose为true或meteor.modern.transpiler.verbose按文件打印[Transpiler] Used SWC .../[Transpiler] Used Babel ...并区分(app)、(package)、(node_modules)上下文.swcrc按 JSON 解析swc.config.js/swc.config.ts在 vm 沙箱中求值。任何对解析器的改动都应同时针对静态.swcrc与动态配置路径验证配置改动未生效时检查initializeMeteorAppSwcrc中的 mtimehash 缓存——只有 mtime 变化动态配置还需解析对象哈希变化时配置才会被重新读取。Rspack Bundler Integration应用源码的打包与 HMRRspack 是 Rust 实现、兼容 Webpack 的打包器集成。用户通过meteor add rspack即可启用Meteor 自身仍拥有包编译、开发服务器生命周期与运行时程序清单本文档覆盖的是两者之间的集成层。维护者指南见 dev/modern-tools/rspack/README.md用户向文档见 rspack-bundler-integration.md。为何引入 Rspack获得更快的冷构建与增量构建同时不放弃 Webpack 生态兼容性loader、plugin、HMR 语义在 Meteor 用于 SSR 与 packages 的同一代码路径上支持现代应用代码模式完整 ESM含exports字段、tree shaking、动态导入、持久化 FS 缓存保持 Meteor packages、Atmosphere 约定与开发服务器流程对应用透明meteor add rspack是唯一必需步骤。双包结构集成拆分为两个包packages/rspackAtmosphere 包构建插件侧package.js注册构建插件并声明运行时包源码见 packages/rspack/package.jsPackage.registerBuildPlugin({ name: rspack, sources: [lib/constants.js, lib/dependencies.js, lib/build-context.js, lib/processes.js, lib/config.js, rspack_plugin.js], use: [modules0.8.2, ecmascript, tools-core], }); Package.onUse(function (api) { api.use(ecmascript, [client, server]); api.use([tools-core, webapp]); api.mainModule(rspack_server.js, server); });lib/下各文件职责文件职责constants.jsrspack/core、meteorjs/rspack、swc-loader等的默认版本构建上下文目录名_build、build-assets、build-chunks、.rsdoctor跨重建跟踪安装/编译状态的GLOBAL_STATE_KEYSdependencies.jsrspack/core、meteorjs/rspack、React HMR、Rsdoctor 的自动安装流程复用 tools-core 的 npm 辅助函数build-context.js创建与清理构建上下文、资源与 chunk 目录管理默认的rspack.config.jsconfig.js根据解析后的应用配置设置 Meteor 入口点与环境变量processes.js派生 Rspack 开发服务器与服务端 watch 进程计算端口选择正确的配置文件.cjs/.mjs/.ts/...处理清理compilation.js首次编译屏障协调 Meteor 服务器启动与 Rspack 首次 emitrspack_plugin.js见 packages/rspack/rspack_plugin.js是在插件沙箱内运行的总指挥检查安装状态、确保构建上下文存在、配置 Meteor、启动 Rspack 进程或执行一次性构建并等待首次编译完成。rspack_server.js是运行在用户应用内的运行时侧通过webapp将 Meteor 与 Rspack 开发服务器组合开发环境做代理中间件生产环境做静态服务。npm-packages/meteor-rspackmeteorjs/rspacknpm 包配置侧用户通过 Atmosphere 包的自动安装流程安装它提供默认 Rspack 配置与defineConfig(factory)辅助函数。路径职责index.js、index.d.ts公共 APIdefineConfig、HtmlRspackPluginrspack.config.js庞大的默认 Rspack 配置client server、SWC loader、插件、externals、HMR、持久化缓存lib/meteorRspackConfigFactory.js构建Meteor.*辅助函数compileWithMeteor、compileWithRspack、extendSwcConfig、replaceSwcConfig、disablePlugins、enablePortableBuild、persistDevFiles、splitVendorChunk、setCache、extendConfiglib/meteorRspackHelpers.js、lib/meteorRspackConfigHelpers.js检测辅助React/Blaze/TS 等、Meteor define 插件值、输出与 externals 接线lib/swc.js解析.swcrc/swc.config.js/swc.config.tsTS 配置使用swc/corelib/localDependenciesHelpers.js用swc/core解析用户rspack.config.js发现本地插件文件并加入 FS 缓存的buildDependencieslib/mergeRulesSplitOverlap.js、lib/ignore.jsmodule rules 的安全合并与 ignore-loader 规则plugins/自定义 Rspack 插件HTML 生成、资源 externals、服务端输出、require externalsscripts/bump-version.js、scripts/publish-beta.sh版本号递增与 beta 发布脚本与 Meteor 的交互方式Rspack并非整体替换 Meteor 的打包器而是分工协作Meteor 仍拥有包编译、boilerplate 生成器、开发服务器生命周期与运行时程序清单Rspack 拥有应用源码编译client 与 server、HMR、资源产出与用户代码的 chunk 图两者在三个点缝合webapp中间件开发时代理到 Rspack 开发服务器生产时服务产出文件、资源 externals 插件使 Meteor packages 对 Rspack 保持 external、入口点环境变量METEOR_CONFIG_CLIENT/METEOR_CONFIG_SERVER/ ...由构建插件通过 tools-core 的setMeteorAppEntrypoints设置。排查集成问题时的常见根因缺失的 externals 绑定、过期的构建上下文目录、未到达打包器的入口点环境变量、或返回了 Rspack 无法正确合并的配置片段。首选排查点是packages/rspack/lib/build-context.js目录状态、packages/rspack/lib/processes.js进程与端口接线、npm-packages/meteor-rspack/rspack.config.js默认值与npm-packages/meteor-rspack/lib/meteorRspackConfigFactory.js辅助函数。Profiler Tooling两套互补的性能工具代码库中存在两套分析器内置的METEOR_PROFILE插桩打印工具内部时间花费与meteor profileCLI针对应用运行受控基准套件。维护流程见 dev/modern-tools/profiler/README.mdmeteor profile的用户文档见 v3-docs/docs/cli/index.md工具内部 profiler 文档见 tools/PERFORMANCE.md。两种工具怎么选METEOR_PROFILE内置工具分析器。设置METEOR_PROFILE阈值ms会让任意meteor命令打印超过阈值的所有插桩调用的自顶向下剖析报告。插桩来自散落在tools/中的Profile.time(...)/Profile.run(...)代码块。适用于调查工具自身的时间去向约束求解、包加载、打包、watcher。meteor profile基准 CLI。用meteor/performance套件包裹meteor run或--build包裹meteor build在受控运行集合上报告构建时间与/或 bundle 体积指标。适用于对比两个分支、两个 Meteor 版本或性能改动的前后差异。一句话总结用METEOR_PROFILE找时间花在哪用meteor profile获得「一次改动省了多少时间或字节」的稳定可复现测量。METEOR_PROFILE的输出形如| (#1) Profiling: ProjectContext prepareProjectForBuild | ProjectContext prepareProjectForBuild..........9,207 ms (1) | _initializeCatalog.............................24 ms (1) | files.readFile 7 ms (2) ... | (#1) Total: 9,544 ms (ProjectContext prepareProjectForBuild)与采样式分析器如node --prof不同这里调用次数是精确的时间为高精度墙钟测量仅展示时取整但容易受 GC、分析器开销与 CPU 竞争干扰。阅读报告前务必参考 tools/PERFORMANCE.md 的 Performance Considerations 一节——缓存冷热、release 与 checkout 模式、硬件与操作系统差异都会显著影响测量结果。若需更深入的诊断METEOR_INSPECT基于 Node.jsinspector模块生成.cpuprofile文件如METEOR_INSPECTbundler.bundle,compiler.compile meteor build ./output-build配合METEOR_INSPECT_OUTPUT、METEOR_INSPECT_INTERVAL、METEOR_INSPECT_MAX_SIZE等环境变量控制行为适合定位 bundler/compiler 等重函数中的具体瓶颈。维护meteor profile脚本CLI 实现位于tools/cli/commands.js上游meteor/performance仓库发布新 tag 或变更监控脚本 API 时需要更新1. 更新固定的 performance 分支定位setupBenchmarkSuite修改branch常量为新 tag// tools/cli/commands.js const repoUrl https://github.com/meteor/performance; const branch v3.5.0; // 提升此分支 tag2. 同步 CLI 参数如需若上游新增 flag如--client-size在doBenchmarkCommand中把新 flag 映射进meteorSizeEnvs环境变量。验证 Profiler 改动Profiler 没有自动化 E2E 覆盖需要手动验证# 1. 准备沙箱环境例如一个 E2E 测试 fixture cd tools/e2e-tests/apps/react # 2. 清除旧 performance 脚本缓存强制重新克隆 rm -rf node_modules/.cache/meteor/performance # 3. 验证默认 profile 运行 meteor profile # 4. 验证特定基准 flag meteor profile --build meteor profile --size meteor profile --size-only # 5. 验证超时确保能正常传播 METEOR_IDLE_TIMEOUT120 meteor profile注意若修改了setupBenchmarkSuite中的克隆逻辑可临时重命名系统tar二进制验证纯git clone回退逻辑也能正常工作。调试注意事项不支持的平台profiler 在原生 Windows 上会提前抛错请使用 WSL 作为变通方案Git 要求脚本要求git 2.25以使用sparse-checkout分支固定branch常量必须固定到具体 tag如v3.4.0绝不使用main防止未经评审的上游改动渗入所有贡献者环境深度剖析将meteor profile与METEOR_PROFILE1 meteor run组合使用可同时获得端到端基准计时与工具内部时间花费的深度追踪。E2E 测试覆盖真实项目驱动的质量保障Rspack 集成由tools/e2e-tests/下的 Jest Playwright 套件验证完整矩阵见 dev/modern-tools/rspack/E2E_COVERAGE.md。每个tools/e2e-tests/apps/name/下的应用 fixture 都有对应的name.test.js对真实 Meteor Rspack 项目执行 init/dev/prod/test/build/reset 各阶段。测试策略真实项目而非 mock每个测试复制应用 fixture、安装依赖、添加rspack包并运行 Meteor CLI可捕获单元测试遗漏的集成 bugHMR 接线、externals、资源路径、Windows 怪癖所有 fixture 走同一生命周期Init、Run(dev)、Run(prod)、Test、Test once、Build、Reset。共享的helpers.js与test-helpers.js强制执行一致的断言集构建产物存在、页面渲染、存在__rspack__脚本、开发环境 HMR 开启而生产关闭Skeleton 同样覆盖skeleton.test.js在独立端口上对每个meteor create --skeleton模板走完相同阶段。每个运行阶段的默认断言构建产物存在、页面标题匹配、body 样式渲染、__rspack__script 标签存在。各阶段含义如下阶段作用Init复制应用、安装依赖、添加 rspack、生成配置Run (dev)meteor run——断言构建产物、应用加载、client/server 热重建Run (prod)meteor run --production——生产模式下的相同检查Testmeteor test——运行 mocha 测试驱动验证测试重建Test oncemeteor test --once——跑完测试检查退出码Buildmeteor build——验证 bundle 结构main.js、programs/server、web.browser、web.browser.legacyResetmeteor reset——清理 rspack 构建产物、缓存、asset/chunk 上下文目录与.meteor/local子目录覆盖矩阵亮点框架与应用类型react、react-router、blaze、full-blaze、typescript、babel、coffeescript、vue、solid、svelte、monorepo、server-only覆盖 JSX/TSX/TS/CoffeeScript/Vue SFC 等环境检测配置能力自定义 rspack config.cjs/.mjs/.ts、rspack.config.override.js、自定义 build dir 与 asset/chunk 目录、Meteor.extendSwcConfig路径别名、Meteor.disablePlugins、meteor.modules配置、CSS 自动委派边界场景ESM-only 包s3mini、ESM 子路径导出modelcontextprotocol/sdk/client/streamableHttp.js、原生 C 绑定bcrypt、node:协议导入、未转译 npm 依赖compileWithRspack、worker 文件解析compileWithMeteor、service worker 与 PWA manifest回归专项unplugin transform 与 buildDependencies 跟踪#14031、Rspack devserver 端口在SIGTERM后释放、绝对路径外部METEOR_LOCAL_DIR、Node Inspector 断点与 source mapSkeleton14 个 skeleton 模板angular、apollo、babel、bare、blaze、chakra-ui、coffeescript、full、react、solid、svelte、tailwind、typescript、typescript-tailwind、vue全阶段验证。常见维护任务升级 SWC 依赖发布新meteorjs/swc-core包装包并滚入 Meteor 核心是同一任务的两个阶段不可拆分——两者必须同步推进使工具路径与 bundler 路径在语法支持上保持一致。阶段 1发布新包装包meteorjs/swc-core。包装包仓库为meteor/meteor-package-install-swc# 1. 克隆或拉取最新包装仓库 git clone https://github.com/meteor/meteor-package-install-swc cd meteor-package-install-swc # 2. 更新包装配置 # - 打开 install.js更新内联 dependencies 块中的 swc/core 版本 # - 打开 package.json将 version 设置为与新 SWC 版本完全一致 # 3. 重新生成 lockfile 并验证 npm install rm -rf .swc node_modules npm install node -e require(./index.js) # 必须无异常加载 # 4. 提交并发布需要 meteorjs npm org 发布权限 git commit -am bump swc/core version to version npm publish --access public # 5. 验证发布成功 npm view meteorjs/swc-core version阶段 2滚入 Meteor 核心1. 更新核心包更新以下文件中的meteorjs/swc-core版本字符串——packages/babel-compiler/package.js顶层Npm.depends、packages/standard-minifier-js/package.js插件Npm.depends。2. 更新 bundler 集成npm 包提升npm-packages/meteor-rspack/package.json中swc/corepeer 依赖范围# 刷新 lockfile cd packages/babel-compiler/.npm/package meteor npm install cd ../../../../packages/standard-minifier-js/.npm/plugin/minifyStdJS meteor npm install cd ../../../../../npm-packages/meteor-rspack npm install3. 更新选项解析器若 SWC API 变更更新compileWithSwc与packages/babel-compiler/babel-compiler.js中的解析器、npm-packages/meteor-rspack/lib/meteorRspackConfigFactory.js及meteorRspackHelpers.js中的 loader 默认值、npm-packages/meteor-rspack/lib/swc.js中的配置解析器。4. 通过测试验证兼容性meteor self-test --file modern.js meteor self-test --file compiler-plugins.js # 提示E2E 套件无法启动时先运行 npm run install:e2e npm run test:e2e5. 提升 Atmosphere 包版本使用.github/skills/version-bump技能提升babel-compiler与standard-minifier-js下游包会自动重新发布。迭代meteorjs/rspacknpm 包修改 npm 包后用npm link链接到本地应用验证# 1. 构建并链接本地 npm 包 cd npm-packages/meteor-rspack npm link # 2. 进入目标应用并链接 cd /path/to/target-app meteor add rspack # 若未添加 meteor npm link meteorjs/rspack meteor run注意Atmosphere 包的自动安装流程可能尝试从 registry 安装更新版本。要让本地链接生效在应用package.json中设置meteor: { autoInstallDeps: false }。手动验证通过后务必运行 E2E 套件确认更广的兼容性npm run test:e2e若报缺依赖先npm run install:e2e。升级 Rspack 核心依赖新版本 Rspack 发布后需提升四类核心依赖rspack/core、rspack/plugin-react-refresh、swc-loader、rsdoctor/rspack-plugin。1. 更新常量Atmosphere 包修改packages/rspack/lib/constants.js中的默认版本// packages/rspack/lib/constants.js const DEFAULT_RSPACK_VERSION 1.0.0-beta.1;2. 更新包配置npm 包提升npm-packages/meteor-rspack/package.json中peerDependencies与devDependencies的版本peer 范围保持新最低版本允许的最宽范围然后npm install刷新 lockfile。3. 验证兼容性从仓库根运行完整 E2E 套件npm run test:e2e。重点关注 Rspack 发布说明中的破坏性变更模块解析exports条件、ESM、node:协议、持久化 FS 缓存布局用户应用可能携带过期缓存、HMR 客户端接线__rspack__script 标签、dev server URL、SWC loader 选项见 dev/modern-tools/swc/README.md。发布包npm-packages/meteor-rspack或packages/rspack有改动时先发布 npm 包后提升 Atmosphere 包版本。Beta 发布# 1. 提升 npm 包版本并发布 beta cd npm-packages/meteor-rspack npm run bump -- patch --beta # 视改动规模使用 patch、minor 或 major npm run publish:beta # 2. 提升 Atmosphere 包版本如 1.0.0-beta.1 # 详细说明见 version-bump 技能正式发布# 1. 提升 npm 包版本并发布 cd npm-packages/meteor-rspack npm run bump -- patch # 视改动规模使用 patch、minor 或 major npm publish # 2. 提升 Atmosphere 包版本如 1.0.0 # 详细说明见 version-bump 技能基准测试重建内存排查重建内存问题时使用scripts/build-stack-memory-bench.js见 dev/modern-tools/rspack/MEMORY_BENCHMARK.md。该脚本由大型应用内存滞留问题PR #14464的调查与修复中创建会重复运行同一重建负载并区分meteor-tool、应用服务器以及 Rspack/TypeScript/MongoDB 等子进程各自的内存占用。⚠️ 请对一次性应用检出运行该基准它会在对比变体时更新.meteor/packages与package.json。被触碰的源文件会在运行结束时恢复但包与 Rspack 配置改动不会恢复。典型运行cd /path/to/meteor APP_PATH/path/to/meteor-large-app/blaze \ TOUCH_FILEserver/main.js \ node scripts/build-stack-memory-bench.js默认matrix模式对每种配置传统 Meteor 打包、默认 Rspack 配置、禁用缓存或 source map 的变体记录首次构建与十次服务端重建并在变体之间重置 Meteor、链接本地meteorjs/rspack检出。每次重建打印进程树采样RSS Total: 2460 MB, Tool: 950 MB, App: 140 MB, Other: 1370 MB, FDs: 48, Procs: 7结束时汇总报告各变体的增长率与增量Variant | Tool Slope | App Slope | Total Slope (MB/rebuild) baseline | 0.8 MB | -0.4 MB | 12.1 MB解读要点Tool Slope上升表示meteor-tool内部压力linker、watcher 或集成滞留toolRSS稳定而otherRSS上升则指向子进程用OTHER PROCESS ATTRIBUTION区分rspack-node、TypeScript checker、MongoDB 等前几次采样权重应降低含首次编译与缓存预热。当meteor-tool是增长方时用MODEleak模式重建到 RSS 阈值并抓取堆快照USE_GLOBALtrue可将同一负载对已安装 Meteor 发行版复测区分 checkout-only 改动与发行版行为。完整选项表MAX_CYCLES、SKIP_RESET、SETTLE_TIME、READY_PATTERN、TOOL_NODE_FLAGS等可用node scripts/build-stack-memory-bench.js --help查看。小结三大支柱如何协同现代构建栈的分工可以概括为一句话Meteor 拥有元数据与生命周期Rspack 拥有应用打包SWC 统一转译与压缩tools-core 提供公共底座Profiler 保证性能可观测。meteor add rspack一键接入、移除即完全清理的包级作用域设计使得这套生态可以独立演进——维护者在升级任一组件时只需遵循本指南中「先 npm 包、后 Atmosphere 包」的发布顺序并用meteor self-test与 Jest Playwright E2E 套件双线验证即可保证工具路径与 bundler 路径在语法与行为上始终一致。【免费下载链接】meteorMeteor, the JavaScript App Platform项目地址: https://gitcode.com/gh_mirrors/me/meteor创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考