Meteor 1.8.2 迁移指南升级 babel/runtime、meteor-node-stubs 与包重发布完整实操【免费下载链接】meteorMeteor, the JavaScript App Platform项目地址: https://gitcode.com/gh_mirrors/me/meteor本篇指南面向从 Meteor 1.8 / 1.8.1 升级到 1.8.2 的应用开发者与 Meteor 包作者系统梳理该版本官方文档要求的三项必做迁移步骤升级babel/runtime、对齐meteor-node-stubs主版本、使用 1.8.2 重新发布包并基于当前仓库源码与 v1.8.2 变更日志 深挖其背后的运行机制与版本约束。读完你不仅能顺利完成升级还能理解babel-runtime包如何在启动时校验 npm 依赖版本、meteor-node-stubs如何为浏览器端提供 Node 内置模块垫片以及包作者应如何处理module.watch未定义等典型报错。迁移前须知1.8.2 的升级定位Meteor 1.8.2发布于 2019-11-14见 docs/history.md的大部分新特性要么在幕后以向后兼容的方式直接生效要么属于可选开启opt-in功能。因此绝大多数应用无需改写业务代码即可升级但官方 1.8.2 迁移指南 明确指出仍有必做的迁移步骤需要手工执行否则升级后可能遇到运行时报错。本指南的迁移范围是1.8 → 1.8.2若你从更早版本1.7 及以下升级请阅读文末的旧版本迁移指引。必做迁移步骤一升级 babel/runtime npm 包官方要求将babel/runtimenpm 包升级到最新版本文档撰写时最新为7.7.2meteor npm install babel/runtimelatest注意这里使用meteor npm而不是裸的npm目的是让安装流程复用 Meteor 发行版内置的 npm 版本与镜像配置保证与 Meteor 工具链兼容。为什么必须升级源码中的版本校验逻辑Meteor 通过内置的babel-runtime包packages/babel-runtime/package.js在服务端挂载 Babel 转译产物所需的运行时辅助函数runtime helpers其入口文件 packages/babel-runtime/babel-runtime.js 会在启动时直接读取babel/runtime/package.json的版本号并做硬性校验若babel/runtime未安装直接抛出错误并提示执行meteor npm install --save babel/runtime若版本号小于7或命中7.0.0-beta.x且 x 小于56则向控制台输出警告要求执行meteor npm install --save babel/runtimelatest。也就是说babel/runtime的版本过低或缺失时Meteor 1.8.2 的 Babel 转译链路无法获得匹配的辅助函数如_extends、inherits、typeof等这正是官方把该升级列为必做的原因。与此相关的编译端逻辑可参考 packages/babel-compiler/babel-compiler.js其中对babel/runtime/helpers/...、regenerator-runtime等模块做了专门处理。关于 Babel runtime helpers 的来龙去脉packages/babel-runtime/README.md 也说明了 Meteor 自维护 helpers 的三点收益兼容 IE 8、当 Babel 编译器升级时保持向后兼容、尽可能压缩客户端代码体积。必做迁移步骤二对齐 meteor-node-stubs 主版本Meteor 1.8.2 创建的新应用默认依赖meteor-node-stubs1.0.0因此官方建议已有应用把该 npm 包也升级到同一主版本meteor npm install meteor-node-stubsnextmeteor-node-stubs是Node 内置模块的浏览器端垫片集合stub implementationsa la Browserify其源码位于 npm-packages/meteor-node-stubs。当前仓库中的版本已演进到1.2.26见 npm-packages/meteor-node-stubs/package.json核心思路与 1.0.0 一致。垫片映射机制map.json 与运行时安装每个 Node 内置模块对应一个浏览器端替代实现或一个空实现映射关系集中定义在 npm-packages/meteor-node-stubs/map.jsonNode 内置模块浏览器端垫片实现assertassert/bufferbuffer/consoleconsole-browserifyconstantsconstants-browserifycrypto../wrappers/crypto.jsdomaindomain-browsereventsevents/httpstream-httphttpshttps-browserifyosos-browserify/browser.jspathpath-browserifyprocessprocess/browser.jsquerystringquerystring-es3/stream及_stream_*readable-stream/stream-browserifystring_decoderstring_decoder/timerstimers-browserifyttytty-browserifyurlurl/util、sysutil/util.jsvmvm-browserifyzlibbrowserify-zlibchild_process、cluster、dgram、dns、fs、net、readline、repl、tlsnull无法在浏览器模拟提供空实现入口 npm-packages/meteor-node-stubs/index.js 会遍历map.json为每个可垫片的模块同时注册id、id.js、node:id三种形式的别名并通过meteorInstall安装到应用根目录上一级的node_modules中避免污染应用与包的命名空间若全局Buffer不存在还会尝试用buffer垫片补上global.Buffer。它如何接入 Meteor 应用应用侧并不需要直接import这个包——modules包的 packages/modules/stubs.js 会在构建期用require.resolve(meteor-node-stubs)探测它是否安装在应用根目录的node_modules中若存在则直接require(meteor-node-stubs)从而让fs、util、http等内置模块在客户端代码中有定义。这就是新应用默认依赖它、旧应用升级后必须对齐版本的原因版本不一致可能导致客户端模块解析行为差异或垫片缺失。必做迁移步骤三包作者请用 1.8.2 重新发布包如果你维护发布在 Atmosphere 上的Meteor 包且在 1.8.2 应用中使用这些包时遇到错误——官方明确举的例子是module.watch未定义——建议按如下步骤处理cd path/to/your/package # 在 package.js 的 Package.onUse 中声明 api.versionsFrom(1.8.2) ... meteor --release 1.8.2 publish要点拆解修改package.js在Package.onUse中添加或更新api.versionsFrom(1.8.2)声明该包针对 1.8.2 API 编译用指定的 Meteor 版本发布meteor --release 1.8.2 publish确保包由 1.8.2 的工具链编译而不是本地默认的其它版本bump 次版本号提升包的 minor 版本后再发布这样 1.8.2 应用会自动解析到新版本从而拿到由 1.8.2 编译的产物。并非所有包都需要重发布官方特别说明以下情况通常不需要重发布近期已用 1.8.1 重新发布过的包位于应用packages/目录下的本地包——它们总是从源码重新编译不存在旧编译产物问题。不过重发布是解决包版本与编译产物错配问题的通用手段能覆盖包版本混乱与编译方式不匹配两大类问题包作者主动处理可以让下游使用者省去大量排查成本。这条建议与 v1.8.2 变更日志中的迁移说明完全一致见 docs/history.md。1.8.2 的 Breaking Changes 与配套更新升级时除了执行上述三条必做步骤还应留意该版本在 docs/history.md 中记录的两项破坏性变更模块级require/exports变量声明不再被自动重命名若模块顶层声明了名为require或exports的变量可能与模块函数参数同名冲突出现Uncaught SyntaxError: Identifier exports has already been declared。迁移时应避免在模块顶层声明这两个保留含义的标识符。Plugin.fs方法一律同步化构建插件中调用Plugin.fs时不再接受回调参数需改为同步调用写法。此外1.8.2 还同步了一批底层依赖与能力更新详见 docs/history.md了解它们有助于判断升级后行为变化运行时与工具链Node 升级到 8.16.2内置 npm 升级到 6.13.0其pacotefork 为 9.5.9meteor-babel升级到 7.7.0reify升级到 0.20.12core-js升级到 3.2.1terser升级到 4.3.1optimism升级到 0.11.3。TypeScript 官方支持新应用默认包含官方typescript包支持.ts/.tsx编译旧应用可meteor add typescript添加meteor create --typescript new-typescript-app可直接创建 TypeScript 骨架内含推荐的tsconfig.json。模块系统打包现代客户端代码时优先使用package.json的module字段服务器仍只用mainlegacy 客户端按browser→main→module顺序import/export/ 动态import()语法在包括node_modules在内的所有模块中默认支持由 Reify 编译器实现如需对node_modules中超出模块语法范围的现代语法重新编译可在应用package.json中通过meteor.nodeModules.recompile选项开启。开发体验构建过程能检测开发期变更的文件是否真正被服务端 bundle 使用未涉及服务端时避免整机重启客户端刷新通常比服务端重启快得多未使用autoupdate的应用可meteor add autoupdate启用客户端刷新。数据库与文件扩展名npm-mongo使用的mongodbnpm 包升级到 3.2.7ecmascript编译插件在.js、.jsx之外自动支持.mjs扩展名。从 1.8 以下版本迁移本指南仅覆盖1.8 → 1.8.2。如果你的应用仍运行在 1.7 或更早版本中间跨过的每个版本都有各自的迁移要点官方建议逐级阅读对应指南Migrating to Meteor 1.8从 1.7 升级Migrating to Meteor 1.7从 1.6 升级Migrating to Meteor 1.6从 1.5 升级Migrating to Meteor 1.5从 1.4 升级Migrating to Meteor 1.4从 1.3 升级Migrating to Meteor 1.3从 1.2 升级迁移后验证清单完成上述操作后可通过以下方式快速验证迁移是否到位校验运行时依赖版本在应用根目录执行meteor npm ls babel/runtime meteor-node-stubs确认babel/runtime为 7.x文档时代为 7.7.2 及以上、meteor-node-stubs为 1.x观察启动日志meteor run启动时若控制台出现babel/runtime ... is out of date警告说明版本校验packages/babel-runtime/babel-runtime.js仍未通过需再次执行升级命令回归客户端构建检查应用代码中对Buffer、process、util等 Node 内置模块的浏览器端引用是否正常解析依赖 npm-packages/meteor-node-stubs 的垫片链路包作者额外确认若使用自定义 Atmosphere 包验证其package.js中的api.versionsFrom已声明为1.8.2且已用meteor --release 1.8.2 publish重新发布应用侧应能自动解析到新版本产物。只要三条必做迁移步骤全部落实并规避require/exports顶层声明与Plugin.fs回调用法这两项破坏性变更应用即可平稳运行在 Meteor 1.8.2 之上。【免费下载链接】meteorMeteor, the JavaScript App Platform项目地址: https://gitcode.com/gh_mirrors/me/meteor创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Meteor 1.8.2 迁移指南：升级 @babel/runtime、meteor-node-stubs 与包重发布完整实操
Meteor 1.8.2 迁移指南升级 babel/runtime、meteor-node-stubs 与包重发布完整实操【免费下载链接】meteorMeteor, the JavaScript App Platform项目地址: https://gitcode.com/gh_mirrors/me/meteor本篇指南面向从 Meteor 1.8 / 1.8.1 升级到 1.8.2 的应用开发者与 Meteor 包作者系统梳理该版本官方文档要求的三项必做迁移步骤升级babel/runtime、对齐meteor-node-stubs主版本、使用 1.8.2 重新发布包并基于当前仓库源码与 v1.8.2 变更日志 深挖其背后的运行机制与版本约束。读完你不仅能顺利完成升级还能理解babel-runtime包如何在启动时校验 npm 依赖版本、meteor-node-stubs如何为浏览器端提供 Node 内置模块垫片以及包作者应如何处理module.watch未定义等典型报错。迁移前须知1.8.2 的升级定位Meteor 1.8.2发布于 2019-11-14见 docs/history.md的大部分新特性要么在幕后以向后兼容的方式直接生效要么属于可选开启opt-in功能。因此绝大多数应用无需改写业务代码即可升级但官方 1.8.2 迁移指南 明确指出仍有必做的迁移步骤需要手工执行否则升级后可能遇到运行时报错。本指南的迁移范围是1.8 → 1.8.2若你从更早版本1.7 及以下升级请阅读文末的旧版本迁移指引。必做迁移步骤一升级 babel/runtime npm 包官方要求将babel/runtimenpm 包升级到最新版本文档撰写时最新为7.7.2meteor npm install babel/runtimelatest注意这里使用meteor npm而不是裸的npm目的是让安装流程复用 Meteor 发行版内置的 npm 版本与镜像配置保证与 Meteor 工具链兼容。为什么必须升级源码中的版本校验逻辑Meteor 通过内置的babel-runtime包packages/babel-runtime/package.js在服务端挂载 Babel 转译产物所需的运行时辅助函数runtime helpers其入口文件 packages/babel-runtime/babel-runtime.js 会在启动时直接读取babel/runtime/package.json的版本号并做硬性校验若babel/runtime未安装直接抛出错误并提示执行meteor npm install --save babel/runtime若版本号小于7或命中7.0.0-beta.x且 x 小于56则向控制台输出警告要求执行meteor npm install --save babel/runtimelatest。也就是说babel/runtime的版本过低或缺失时Meteor 1.8.2 的 Babel 转译链路无法获得匹配的辅助函数如_extends、inherits、typeof等这正是官方把该升级列为必做的原因。与此相关的编译端逻辑可参考 packages/babel-compiler/babel-compiler.js其中对babel/runtime/helpers/...、regenerator-runtime等模块做了专门处理。关于 Babel runtime helpers 的来龙去脉packages/babel-runtime/README.md 也说明了 Meteor 自维护 helpers 的三点收益兼容 IE 8、当 Babel 编译器升级时保持向后兼容、尽可能压缩客户端代码体积。必做迁移步骤二对齐 meteor-node-stubs 主版本Meteor 1.8.2 创建的新应用默认依赖meteor-node-stubs1.0.0因此官方建议已有应用把该 npm 包也升级到同一主版本meteor npm install meteor-node-stubsnextmeteor-node-stubs是Node 内置模块的浏览器端垫片集合stub implementationsa la Browserify其源码位于 npm-packages/meteor-node-stubs。当前仓库中的版本已演进到1.2.26见 npm-packages/meteor-node-stubs/package.json核心思路与 1.0.0 一致。垫片映射机制map.json 与运行时安装每个 Node 内置模块对应一个浏览器端替代实现或一个空实现映射关系集中定义在 npm-packages/meteor-node-stubs/map.jsonNode 内置模块浏览器端垫片实现assertassert/bufferbuffer/consoleconsole-browserifyconstantsconstants-browserifycrypto../wrappers/crypto.jsdomaindomain-browsereventsevents/httpstream-httphttpshttps-browserifyosos-browserify/browser.jspathpath-browserifyprocessprocess/browser.jsquerystringquerystring-es3/stream及_stream_*readable-stream/stream-browserifystring_decoderstring_decoder/timerstimers-browserifyttytty-browserifyurlurl/util、sysutil/util.jsvmvm-browserifyzlibbrowserify-zlibchild_process、cluster、dgram、dns、fs、net、readline、repl、tlsnull无法在浏览器模拟提供空实现入口 npm-packages/meteor-node-stubs/index.js 会遍历map.json为每个可垫片的模块同时注册id、id.js、node:id三种形式的别名并通过meteorInstall安装到应用根目录上一级的node_modules中避免污染应用与包的命名空间若全局Buffer不存在还会尝试用buffer垫片补上global.Buffer。它如何接入 Meteor 应用应用侧并不需要直接import这个包——modules包的 packages/modules/stubs.js 会在构建期用require.resolve(meteor-node-stubs)探测它是否安装在应用根目录的node_modules中若存在则直接require(meteor-node-stubs)从而让fs、util、http等内置模块在客户端代码中有定义。这就是新应用默认依赖它、旧应用升级后必须对齐版本的原因版本不一致可能导致客户端模块解析行为差异或垫片缺失。必做迁移步骤三包作者请用 1.8.2 重新发布包如果你维护发布在 Atmosphere 上的Meteor 包且在 1.8.2 应用中使用这些包时遇到错误——官方明确举的例子是module.watch未定义——建议按如下步骤处理cd path/to/your/package # 在 package.js 的 Package.onUse 中声明 api.versionsFrom(1.8.2) ... meteor --release 1.8.2 publish要点拆解修改package.js在Package.onUse中添加或更新api.versionsFrom(1.8.2)声明该包针对 1.8.2 API 编译用指定的 Meteor 版本发布meteor --release 1.8.2 publish确保包由 1.8.2 的工具链编译而不是本地默认的其它版本bump 次版本号提升包的 minor 版本后再发布这样 1.8.2 应用会自动解析到新版本从而拿到由 1.8.2 编译的产物。并非所有包都需要重发布官方特别说明以下情况通常不需要重发布近期已用 1.8.1 重新发布过的包位于应用packages/目录下的本地包——它们总是从源码重新编译不存在旧编译产物问题。不过重发布是解决包版本与编译产物错配问题的通用手段能覆盖包版本混乱与编译方式不匹配两大类问题包作者主动处理可以让下游使用者省去大量排查成本。这条建议与 v1.8.2 变更日志中的迁移说明完全一致见 docs/history.md。1.8.2 的 Breaking Changes 与配套更新升级时除了执行上述三条必做步骤还应留意该版本在 docs/history.md 中记录的两项破坏性变更模块级require/exports变量声明不再被自动重命名若模块顶层声明了名为require或exports的变量可能与模块函数参数同名冲突出现Uncaught SyntaxError: Identifier exports has already been declared。迁移时应避免在模块顶层声明这两个保留含义的标识符。Plugin.fs方法一律同步化构建插件中调用Plugin.fs时不再接受回调参数需改为同步调用写法。此外1.8.2 还同步了一批底层依赖与能力更新详见 docs/history.md了解它们有助于判断升级后行为变化运行时与工具链Node 升级到 8.16.2内置 npm 升级到 6.13.0其pacotefork 为 9.5.9meteor-babel升级到 7.7.0reify升级到 0.20.12core-js升级到 3.2.1terser升级到 4.3.1optimism升级到 0.11.3。TypeScript 官方支持新应用默认包含官方typescript包支持.ts/.tsx编译旧应用可meteor add typescript添加meteor create --typescript new-typescript-app可直接创建 TypeScript 骨架内含推荐的tsconfig.json。模块系统打包现代客户端代码时优先使用package.json的module字段服务器仍只用mainlegacy 客户端按browser→main→module顺序import/export/ 动态import()语法在包括node_modules在内的所有模块中默认支持由 Reify 编译器实现如需对node_modules中超出模块语法范围的现代语法重新编译可在应用package.json中通过meteor.nodeModules.recompile选项开启。开发体验构建过程能检测开发期变更的文件是否真正被服务端 bundle 使用未涉及服务端时避免整机重启客户端刷新通常比服务端重启快得多未使用autoupdate的应用可meteor add autoupdate启用客户端刷新。数据库与文件扩展名npm-mongo使用的mongodbnpm 包升级到 3.2.7ecmascript编译插件在.js、.jsx之外自动支持.mjs扩展名。从 1.8 以下版本迁移本指南仅覆盖1.8 → 1.8.2。如果你的应用仍运行在 1.7 或更早版本中间跨过的每个版本都有各自的迁移要点官方建议逐级阅读对应指南Migrating to Meteor 1.8从 1.7 升级Migrating to Meteor 1.7从 1.6 升级Migrating to Meteor 1.6从 1.5 升级Migrating to Meteor 1.5从 1.4 升级Migrating to Meteor 1.4从 1.3 升级Migrating to Meteor 1.3从 1.2 升级迁移后验证清单完成上述操作后可通过以下方式快速验证迁移是否到位校验运行时依赖版本在应用根目录执行meteor npm ls babel/runtime meteor-node-stubs确认babel/runtime为 7.x文档时代为 7.7.2 及以上、meteor-node-stubs为 1.x观察启动日志meteor run启动时若控制台出现babel/runtime ... is out of date警告说明版本校验packages/babel-runtime/babel-runtime.js仍未通过需再次执行升级命令回归客户端构建检查应用代码中对Buffer、process、util等 Node 内置模块的浏览器端引用是否正常解析依赖 npm-packages/meteor-node-stubs 的垫片链路包作者额外确认若使用自定义 Atmosphere 包验证其package.js中的api.versionsFrom已声明为1.8.2且已用meteor --release 1.8.2 publish重新发布应用侧应能自动解析到新版本产物。只要三条必做迁移步骤全部落实并规避require/exports顶层声明与Plugin.fs回调用法这两项破坏性变更应用即可平稳运行在 Meteor 1.8.2 之上。【免费下载链接】meteorMeteor, the JavaScript App Platform项目地址: https://gitcode.com/gh_mirrors/me/meteor创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考