Meteor 1.9 遷移指南Node.js 12 升級與 32 位 Unix 支持終止【免費下載鏈接】meteorMeteor, the JavaScript App Platform項目地址: https://gitcode.com/gh_mirrors/me/meteorMeteor 1.9 是一個以運行時升級為核心、幾乎完全向后兼容的版本其絕大多數(shù)新特性要么在幕后直接應(yīng)用要么以 opt-in可選啟用方式提供。本篇指南基于 guide/source/1.9-migration.md 展開聚焦從 Meteor 1.8.3 升級到 1.9 時必須知曉的唯一重大破壞性變更——32 位 Unix 支持終止同時結(jié)合倉庫源碼與 docs/history.md 中的版本記錄深入講解 Node.js 12 升級、Fibers 4.0.3、Meteor.user()字段選擇器等新能力幫助讀者順利完成遷移并規(guī)避踩坑。升級方式總覽向后兼容與 opt-inMeteor 1.9 的變更策略可以概括為兩條原則向后兼容behind the scenes大部分底層依賴升級如 Node.js、Fibers、sqlite3直接替換應(yīng)用代碼無需改動可選啟用opt-in新增 API 全部是增量能力只有主動使用新參數(shù)才會生效不會破壞既有代碼。因此對絕大多數(shù)應(yīng)用而言升級動作本身即是meteor update或在 CI/腳本場景下使用meteor update --release 1.9指定版本無需額外的代碼遷移步驟——唯一的例外是下面這條破壞性變更。重大破壞性變更停止支持 32 位 Unix 版本這是 Meteor 1.9 官方遷移文檔中唯一被明確標(biāo)記的 breaking change由于 Node.js 12 不再支持 32 位 LinuxMeteor 1.9 也隨之放棄了對 32 位 Linux 的支持。換言之Meteor 1.9 支持 64 位 Mac、64 位 Windows、64 位 Linux以及 32 位 Windows。在 docs/history.md 的 v1.9 版本記錄中這一變更被同樣明確列為唯一的 Breaking change。升級后支持的平臺矩陣如下平臺架構(gòu)1.8.3 及以前1.9macOS64 位??Windows64 位??Windows32 位??Linux64 位??Linux32 位??不再支持影響與應(yīng)對如果你或你的部署環(huán)境仍在使用 32 位 Linux例如某些 32 位云主機或 ARM 兼容模擬環(huán)境升級到 1.9 前必須先將構(gòu)建與運行環(huán)境切換為 64 位 Linux。這一決策的根因是上游 Node.js 12 本身已停止發(fā)布 32 位 Linux 二進制Meteor 作為依賴 Node.js 運行時平臺的框架只能同步跟進。從倉庫當(dāng)前構(gòu)建腳本 scripts/build-dev-bundle-common.sh 也能看到dev bundle 只針對linux-x64、linux-arm64、darwin-x64、darwin-arm64等 64 位架構(gòu)產(chǎn)出linux-x86的下載分支在該版本之后已不再被使用。底層運行時升級Node.js 12 與核心依賴雖然遷移文檔強調(diào)無需動作但理解底層發(fā)生了什么是升級后排查問題的基礎(chǔ)。根據(jù) docs/history.mdMeteor 1.9 對運行時依賴做了一輪集中升級Node.js8.17.0 → 12.14.0。這是自 Meteor 1.8.3 以來跨越 9、10、11 三個大版本的跳級意味著 V8 引擎、npm6.x、標(biāo)準(zhǔn)庫 API 能力整體提升一個時代。若你的應(yīng)用或依賴包中使用了舊版本 Node 特有的行為如被廢棄的domain模塊用法、舊的 Buffer API 約定需要重點回歸測試fibersnpm 包4.0.3。新版本包含大幅降低重度 Fiber 使用場景下 GC 壓力的改動。由于 Meteor 服務(wù)端方法、發(fā)布訂閱都運行在 Fiber 上下文中這對高并發(fā)服務(wù)端應(yīng)用是直接利好pathwatcher升級為 8.0.2 的 fork 版本應(yīng)用了上游 PR #128 的修復(fù)影響文件監(jiān)視器的穩(wěn)定性sqlite34.1.0供本地開發(fā)數(shù)據(jù)庫相關(guān)工具鏈?zhǔn)褂胣ode-gyp6.0.1node-pre-gyp0.14.0改善原生 npm 模塊在 Node 12 下的編譯兼容性。這些變更在升級時自動生效無需手動修改代碼。1.9 系列后續(xù)補丁版本又對 Node.js 做了兩次跟進1.9.12020-02-18Node.js 升級到 12.16.0包含安全更新見 docs/history.md1.9.22020-02-20Node.js 升級到 12.16.1修復(fù) 12.16.0 引入的若干回歸同時meteor-babel更新到 7.8.2、typescript更新到 3.7.5見 docs/history.md。因此從 1.8.3 直接升到最新的 1.9.x 補丁版本如 1.9.2/1.9.3一次性拿到的是 Node 12.16.x 的完整修復(fù)棧。新增能力用戶文檔字段選擇器Meteor 1.9 引入了兩個實用的 opt-in API用于解決用戶文檔過大導(dǎo)致Meteor.user()拉取冗余數(shù)據(jù)的性能問題對應(yīng) Issue #10469詳見 docs/history.md。Meteor.user()等函數(shù)支持options參數(shù)Meteor.user()、Meteor.findUserByEmail()、Meteor.findUserByUserName()現(xiàn)在可以接收一個options參數(shù)來限制返回字段// 服務(wù)端只取昵稱字段減少 DB 帶寬與客戶端響應(yīng)體積 const user Meteor.user({ fields: { profile.name: 1 } }); // 通過郵箱查找時同樣支持 const target Meteor.findUserByEmail(aexample.com, { fields: { emails: 1 } });這對服務(wù)端而言意味著更少的數(shù)據(jù)庫讀取量對客戶端而言則避免了不必要的響應(yīng)式 UI 更新因為字段選擇會直接影響發(fā)布的數(shù)據(jù)形狀。Accounts.config({ defaultFieldSelector })更進一步的機制是Accounts.config()新增的defaultFieldSelector選項。它會對所有未顯式指定字段選擇器的Meteor.user()/Meteor.findUserBy...()調(diào)用以及所有onLogin、onLogout、onLoginFailure回調(diào)生效import { Accounts } from meteor/accounts-base; Accounts.config({ // 默認(rèn)不返回龐大的交易記錄字段 defaultFieldSelector: { transactions: 0 }, }); // 未顯式傳 fields 時自動應(yīng)用 defaultFieldSelector const user Meteor.user();源碼級原理該選項的合并邏輯實現(xiàn)在 packages/accounts-base/accounts_common.js 的_addDefaultFieldSelector方法中規(guī)則如下未配置defaultFieldSelector時直接返回原options最常見路徑零開銷調(diào)用方未提供fields時自動填入defaultFieldSelector調(diào)用方顯式傳入空對象{}表示明確要完整用戶對象此時尊重顯式意圖不使用默認(rèn)選擇器調(diào)用方的fields為正投影如{ name: 1 }時說明調(diào)用方已明確指定所需字段忽略默認(rèn)選擇器調(diào)用方的fields為負(fù)投影如{ secret: 0 }時如果默認(rèn)選擇器也是負(fù)投影則合并兩者如果默認(rèn)選擇器是正投影則直接使用調(diào)用方的字段。類型定義見 packages/accounts-base/accounts-base.d.ts對應(yīng)的行為測試見 packages/accounts-base/accounts_client_tests.js。適用場景當(dāng)用戶文檔上掛載了大量不常需要的數(shù)據(jù)如不斷增長的歷史交易列表、日志快照時通過defaultFieldSelector可以在全局層面避免每次Meteor.user()調(diào)用都全量拉取這些字段。同時1.9 也對accounts-base與accounts-password內(nèi)部的大量Meteor.user()調(diào)用補充了顯式字段選擇器僅取出各自函數(shù)真正需要的字段。其他值得關(guān)注的變更移除啟動崩潰自動重啟特性舊版本在應(yīng)用啟動階段崩潰時會最多自動重啟兩次對應(yīng) Meteor feature request #335見 docs/history.md。該行為在 1.9 中被移除——升級后若應(yīng)用在啟動時崩潰進程將直接退出而非反復(fù)重啟依賴自動重啟機制的運維腳本需要自行處理Facebook OAuth 切換到 v5 API 端點使用accounts-facebook/facebook-oauth的應(yīng)用升級后需回歸測試登錄流程見 docs/history.mdnpm 生態(tài)同步meteor-babel、typescript等編譯鏈依賴隨 1.9.x 補丁持續(xù)更新保證對更新 ECMAScript 語法與 TypeScript 版本的支持。1.9.3MongoDB retryWrites 的注意點若你準(zhǔn)備直接升到 1.9 系列的最新補丁 1.9.32020-03-09還需注意 MongoDB 驅(qū)動的行為變化。1.9.3 將 MongoDBretryWrites選項的默認(rèn)值從false改為true并將mongodb驅(qū)動從 3.2.7 升級到 3.5.4見 docs/history.md。如果 MongoDB 部署如某些托管服務(wù)不支持可重試寫入連接時會報錯MongoError: This MongoDB deployment does not support retryable writes. Please add retryWritesfalse to your connection string.解決方式是在 MongoDB 連接串中顯式追加retryWritesfalse詳見 guide/source/1.9.3-migration.md。從 1.8.3 之前版本升級怎么辦本指南覆蓋的范圍是1.8.3 → 1.9。如果你的應(yīng)用停留在更早的版本請先逐級閱讀對應(yīng)的歷史遷移指南因為早期版本包含各自獨立的遷移注意事項如 1.8.3 的 jQuery npm 化、1.3 的模塊體系等Migrating to Meteor 1.8.3從 1.8.2Migrating to Meteor 1.8.2從 1.8Migrating to Meteor 1.8從 1.7Migrating to Meteor 1.7從 1.6Migrating to Meteor 1.6從 1.5Migrating to Meteor 1.5從 1.4Migrating to Meteor 1.4從 1.3Migrating to Meteor 1.3從 1.2遷移檢查清單結(jié)合上文從 1.8.3 升級到 1.9 的完整檢查清單如下確認(rèn)構(gòu)建環(huán)境架構(gòu)為 64 位Linux 32 位環(huán)境必須先行遷移否則無法運行 1.9執(zhí)行升級在應(yīng)用目錄運行meteor update或meteor update --release 1.9.x鎖定系列版本回歸測試 Node 12 兼容性重點驗證使用原生 npm 模塊依賴 node-gyp 編譯的應(yīng)用能否正常構(gòu)建運行回歸登錄鏈路若使用 Facebook 登錄驗證 OAuth v5 端點下的登錄/授權(quán)流程檢查啟動腳本確認(rèn)沒有依賴啟動崩潰自動重啟兩次行為的運維邏輯按需啟用新 API存在超大用戶文檔時評估Meteor.user({ fields })與Accounts.config({ defaultFieldSelector })的優(yōu)化收益若升到 1.9.3在 MongoDB 不支持可重試寫入時為連接串追加retryWritesfalse。完整的 1.9 版本變更清單可查閱倉庫內(nèi)的 docs/history.md若計劃繼續(xù)升級到后續(xù)版本可參考 Migrating to Meteor 1.9.3 與 Migrating to Meteor 1.10其中包含 1.9.3 → 1.10 階段 MongoDB featureCompatibilityVersion 升級與 Cordova 9 升級等注意事項?！久赓M下載鏈接】meteorMeteor, the JavaScript App Platform項目地址: https://gitcode.com/gh_mirrors/me/meteor創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 Meteor 1.9 遷移指南：Node.js 12 升級與 32 位 Unix 支持終止
Meteor 1.9 遷移指南Node.js 12 升級與 32 位 Unix 支持終止【免費下載鏈接】meteorMeteor, the JavaScript App Platform項目地址: https://gitcode.com/gh_mirrors/me/meteorMeteor 1.9 是一個以運行時升級為核心、幾乎完全向后兼容的版本其絕大多數(shù)新特性要么在幕后直接應(yīng)用要么以 opt-in可選啟用方式提供。本篇指南基于 guide/source/1.9-migration.md 展開聚焦從 Meteor 1.8.3 升級到 1.9 時必須知曉的唯一重大破壞性變更——32 位 Unix 支持終止同時結(jié)合倉庫源碼與 docs/history.md 中的版本記錄深入講解 Node.js 12 升級、Fibers 4.0.3、Meteor.user()字段選擇器等新能力幫助讀者順利完成遷移并規(guī)避踩坑。升級方式總覽向后兼容與 opt-inMeteor 1.9 的變更策略可以概括為兩條原則向后兼容behind the scenes大部分底層依賴升級如 Node.js、Fibers、sqlite3直接替換應(yīng)用代碼無需改動可選啟用opt-in新增 API 全部是增量能力只有主動使用新參數(shù)才會生效不會破壞既有代碼。因此對絕大多數(shù)應(yīng)用而言升級動作本身即是meteor update或在 CI/腳本場景下使用meteor update --release 1.9指定版本無需額外的代碼遷移步驟——唯一的例外是下面這條破壞性變更。重大破壞性變更停止支持 32 位 Unix 版本這是 Meteor 1.9 官方遷移文檔中唯一被明確標(biāo)記的 breaking change由于 Node.js 12 不再支持 32 位 LinuxMeteor 1.9 也隨之放棄了對 32 位 Linux 的支持。換言之Meteor 1.9 支持 64 位 Mac、64 位 Windows、64 位 Linux以及 32 位 Windows。在 docs/history.md 的 v1.9 版本記錄中這一變更被同樣明確列為唯一的 Breaking change。升級后支持的平臺矩陣如下平臺架構(gòu)1.8.3 及以前1.9macOS64 位??Windows64 位??Windows32 位??Linux64 位??Linux32 位??不再支持影響與應(yīng)對如果你或你的部署環(huán)境仍在使用 32 位 Linux例如某些 32 位云主機或 ARM 兼容模擬環(huán)境升級到 1.9 前必須先將構(gòu)建與運行環(huán)境切換為 64 位 Linux。這一決策的根因是上游 Node.js 12 本身已停止發(fā)布 32 位 Linux 二進制Meteor 作為依賴 Node.js 運行時平臺的框架只能同步跟進。從倉庫當(dāng)前構(gòu)建腳本 scripts/build-dev-bundle-common.sh 也能看到dev bundle 只針對linux-x64、linux-arm64、darwin-x64、darwin-arm64等 64 位架構(gòu)產(chǎn)出linux-x86的下載分支在該版本之后已不再被使用。底層運行時升級Node.js 12 與核心依賴雖然遷移文檔強調(diào)無需動作但理解底層發(fā)生了什么是升級后排查問題的基礎(chǔ)。根據(jù) docs/history.mdMeteor 1.9 對運行時依賴做了一輪集中升級Node.js8.17.0 → 12.14.0。這是自 Meteor 1.8.3 以來跨越 9、10、11 三個大版本的跳級意味著 V8 引擎、npm6.x、標(biāo)準(zhǔn)庫 API 能力整體提升一個時代。若你的應(yīng)用或依賴包中使用了舊版本 Node 特有的行為如被廢棄的domain模塊用法、舊的 Buffer API 約定需要重點回歸測試fibersnpm 包4.0.3。新版本包含大幅降低重度 Fiber 使用場景下 GC 壓力的改動。由于 Meteor 服務(wù)端方法、發(fā)布訂閱都運行在 Fiber 上下文中這對高并發(fā)服務(wù)端應(yīng)用是直接利好pathwatcher升級為 8.0.2 的 fork 版本應(yīng)用了上游 PR #128 的修復(fù)影響文件監(jiān)視器的穩(wěn)定性sqlite34.1.0供本地開發(fā)數(shù)據(jù)庫相關(guān)工具鏈?zhǔn)褂胣ode-gyp6.0.1node-pre-gyp0.14.0改善原生 npm 模塊在 Node 12 下的編譯兼容性。這些變更在升級時自動生效無需手動修改代碼。1.9 系列后續(xù)補丁版本又對 Node.js 做了兩次跟進1.9.12020-02-18Node.js 升級到 12.16.0包含安全更新見 docs/history.md1.9.22020-02-20Node.js 升級到 12.16.1修復(fù) 12.16.0 引入的若干回歸同時meteor-babel更新到 7.8.2、typescript更新到 3.7.5見 docs/history.md。因此從 1.8.3 直接升到最新的 1.9.x 補丁版本如 1.9.2/1.9.3一次性拿到的是 Node 12.16.x 的完整修復(fù)棧。新增能力用戶文檔字段選擇器Meteor 1.9 引入了兩個實用的 opt-in API用于解決用戶文檔過大導(dǎo)致Meteor.user()拉取冗余數(shù)據(jù)的性能問題對應(yīng) Issue #10469詳見 docs/history.md。Meteor.user()等函數(shù)支持options參數(shù)Meteor.user()、Meteor.findUserByEmail()、Meteor.findUserByUserName()現(xiàn)在可以接收一個options參數(shù)來限制返回字段// 服務(wù)端只取昵稱字段減少 DB 帶寬與客戶端響應(yīng)體積 const user Meteor.user({ fields: { profile.name: 1 } }); // 通過郵箱查找時同樣支持 const target Meteor.findUserByEmail(aexample.com, { fields: { emails: 1 } });這對服務(wù)端而言意味著更少的數(shù)據(jù)庫讀取量對客戶端而言則避免了不必要的響應(yīng)式 UI 更新因為字段選擇會直接影響發(fā)布的數(shù)據(jù)形狀。Accounts.config({ defaultFieldSelector })更進一步的機制是Accounts.config()新增的defaultFieldSelector選項。它會對所有未顯式指定字段選擇器的Meteor.user()/Meteor.findUserBy...()調(diào)用以及所有onLogin、onLogout、onLoginFailure回調(diào)生效import { Accounts } from meteor/accounts-base; Accounts.config({ // 默認(rèn)不返回龐大的交易記錄字段 defaultFieldSelector: { transactions: 0 }, }); // 未顯式傳 fields 時自動應(yīng)用 defaultFieldSelector const user Meteor.user();源碼級原理該選項的合并邏輯實現(xiàn)在 packages/accounts-base/accounts_common.js 的_addDefaultFieldSelector方法中規(guī)則如下未配置defaultFieldSelector時直接返回原options最常見路徑零開銷調(diào)用方未提供fields時自動填入defaultFieldSelector調(diào)用方顯式傳入空對象{}表示明確要完整用戶對象此時尊重顯式意圖不使用默認(rèn)選擇器調(diào)用方的fields為正投影如{ name: 1 }時說明調(diào)用方已明確指定所需字段忽略默認(rèn)選擇器調(diào)用方的fields為負(fù)投影如{ secret: 0 }時如果默認(rèn)選擇器也是負(fù)投影則合并兩者如果默認(rèn)選擇器是正投影則直接使用調(diào)用方的字段。類型定義見 packages/accounts-base/accounts-base.d.ts對應(yīng)的行為測試見 packages/accounts-base/accounts_client_tests.js。適用場景當(dāng)用戶文檔上掛載了大量不常需要的數(shù)據(jù)如不斷增長的歷史交易列表、日志快照時通過defaultFieldSelector可以在全局層面避免每次Meteor.user()調(diào)用都全量拉取這些字段。同時1.9 也對accounts-base與accounts-password內(nèi)部的大量Meteor.user()調(diào)用補充了顯式字段選擇器僅取出各自函數(shù)真正需要的字段。其他值得關(guān)注的變更移除啟動崩潰自動重啟特性舊版本在應(yīng)用啟動階段崩潰時會最多自動重啟兩次對應(yīng) Meteor feature request #335見 docs/history.md。該行為在 1.9 中被移除——升級后若應(yīng)用在啟動時崩潰進程將直接退出而非反復(fù)重啟依賴自動重啟機制的運維腳本需要自行處理Facebook OAuth 切換到 v5 API 端點使用accounts-facebook/facebook-oauth的應(yīng)用升級后需回歸測試登錄流程見 docs/history.mdnpm 生態(tài)同步meteor-babel、typescript等編譯鏈依賴隨 1.9.x 補丁持續(xù)更新保證對更新 ECMAScript 語法與 TypeScript 版本的支持。1.9.3MongoDB retryWrites 的注意點若你準(zhǔn)備直接升到 1.9 系列的最新補丁 1.9.32020-03-09還需注意 MongoDB 驅(qū)動的行為變化。1.9.3 將 MongoDBretryWrites選項的默認(rèn)值從false改為true并將mongodb驅(qū)動從 3.2.7 升級到 3.5.4見 docs/history.md。如果 MongoDB 部署如某些托管服務(wù)不支持可重試寫入連接時會報錯MongoError: This MongoDB deployment does not support retryable writes. Please add retryWritesfalse to your connection string.解決方式是在 MongoDB 連接串中顯式追加retryWritesfalse詳見 guide/source/1.9.3-migration.md。從 1.8.3 之前版本升級怎么辦本指南覆蓋的范圍是1.8.3 → 1.9。如果你的應(yīng)用停留在更早的版本請先逐級閱讀對應(yīng)的歷史遷移指南因為早期版本包含各自獨立的遷移注意事項如 1.8.3 的 jQuery npm 化、1.3 的模塊體系等Migrating to Meteor 1.8.3從 1.8.2Migrating to Meteor 1.8.2從 1.8Migrating to Meteor 1.8從 1.7Migrating to Meteor 1.7從 1.6Migrating to Meteor 1.6從 1.5Migrating to Meteor 1.5從 1.4Migrating to Meteor 1.4從 1.3Migrating to Meteor 1.3從 1.2遷移檢查清單結(jié)合上文從 1.8.3 升級到 1.9 的完整檢查清單如下確認(rèn)構(gòu)建環(huán)境架構(gòu)為 64 位Linux 32 位環(huán)境必須先行遷移否則無法運行 1.9執(zhí)行升級在應(yīng)用目錄運行meteor update或meteor update --release 1.9.x鎖定系列版本回歸測試 Node 12 兼容性重點驗證使用原生 npm 模塊依賴 node-gyp 編譯的應(yīng)用能否正常構(gòu)建運行回歸登錄鏈路若使用 Facebook 登錄驗證 OAuth v5 端點下的登錄/授權(quán)流程檢查啟動腳本確認(rèn)沒有依賴啟動崩潰自動重啟兩次行為的運維邏輯按需啟用新 API存在超大用戶文檔時評估Meteor.user({ fields })與Accounts.config({ defaultFieldSelector })的優(yōu)化收益若升到 1.9.3在 MongoDB 不支持可重試寫入時為連接串追加retryWritesfalse。完整的 1.9 版本變更清單可查閱倉庫內(nèi)的 docs/history.md若計劃繼續(xù)升級到后續(xù)版本可參考 Migrating to Meteor 1.9.3 與 Migrating to Meteor 1.10其中包含 1.9.3 → 1.10 階段 MongoDB featureCompatibilityVersion 升級與 Cordova 9 升級等注意事項?！久赓M下載鏈接】meteorMeteor, the JavaScript App Platform項目地址: https://gitcode.com/gh_mirrors/me/meteor創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考