TC39 五月進度：Joint Iteration 與 Iterator Includes 升至 Stage 3，Import Text 同步跟進
TC39 Proposals · 2026-05
JavaScript 語言標準委員會 TC39 在 2026 年五月例會後更新了多項提案的推進狀態。Joint Iteration（共同迭代）與 Iterator Includes 雙雙晉升 Stage 3，意味著規格已趨於穩定、引擎可開始實作；同時期的 Import Text（文字資源匯入）也從更早的審查階段進入 Stage 3。
核心改動
Joint Iteration 由 Michael Ficarra 領軍，允許程式碼以單一迴圈同步推進多個可迭代物件（iterables），概念上類似 Python 的 zip()，但整合進 JavaScript 的迭代器協議。與現有的 Array.prototype.zip（目前尚在更早期）的差別在於它直接操作懶求值的迭代器，不需先展開為陣列。
Iterator Includes 同樣由 Ficarra 提出，對 Iterator 物件新增 .includes() 方法，讓開發者不需先呼叫 .toArray() 就能檢查迭代器中是否含有特定值。在處理無限序列或大型懶求值流時，這個方法在找到目標後可以提前停止，避免無謂的記憶體分配。
Import Text 由 Eemeli Aro 主導，進入 Stage 3 後允許以 import text from "./template.html" with { type: "text" } 語法匯入純文字資源，與 import bytes（Stage 2.7）形成互補的模組資源匯入體系。這樣的設計讓打包工具、瀏覽器和伺服器執行環境都能用統一的靜態分析方式追蹤文字依賴關係。
影響範圍
Stage 3 代表規格文字已完整，但實作仍由各引擎自行決定時程。V8、SpiderMonkey、JavaScriptCore 通常在此階段後六至十二個月推出旗艦功能；在此之前，開發者可透過 Babel 外掛或 core-js polyfill 在生產環境提前使用。對 bundler 生態來說，Import Text 的影響更直接——webpack、Rollup 和 Vite 已在觀察規格定稿，預計在 Stage 4 前後推出原生支援。
與此同時，Immutable ArrayBuffers（Stage 2.7）和 Import Bytes（Stage 2.7）持續在最終規格細節上收斂。Immutable ArrayBuffers 由 Mark Miller 等人主導，目標是允許建立不可修改的 ArrayBuffer，在 Wasm 邊界、SharedArrayBuffer 共享場景中提供更嚴格的記憶體安全語義。
Obsidian 插件生態系重構：社群目錄、自動化安全掃描與開發者儀表板
Obsidian · 2026-05-12
Obsidian 在 2026 年五月宣布對插件發行流程進行大幅重設計，核心是新的 社群目錄平台（community.obsidian.md）上線，取代舊有純靠 GitHub 審核的人工流程，並強制要求所有新舊版本通過自動化安全與品質檢測。
自動化審核機制
新系統對每次提交的插件版本進行靜態程式碼掃描，項目包含惡意程式偵測、高危 API 呼叫識別、依賴套件已知漏洞比對。Obsidian 表示「每個版本現在都會自動進行程式碼品質與安全性檢查」，審核結果通常在數分鐘內完成。高流量插件、社群標記或人工申請複審的專案則進入額外的人工審核佇列。
能力聲明是另一個重要新增：插件必須明確宣告是否存取網路、檔案系統、剪貼簿。這些聲明未來將顯示在插件頁面的安全評分卡（Safety Scorecard）中，讓使用者在安裝前能看到實際的系統存取需求。
開發者工作流程變化
開發者需要建立 Obsidian 帳號並連結 GitHub 身分，才能透過開發者儀表板提交或管理插件。系統在 2026 年推出時已自動遷移既有的 2,300+ 筆排隊審核案例。舊系統核准的插件取得寬限期（移除時程待定），但所有新提交必須通過自動化審核後才能在應用程式內搜尋欄位中出現；未通過者在 24 小時內從搜尋結果下架。
審核通過的版本同樣在 24 小時內同步至應用程式內搜尋。插件頁面新增依下載量、人氣、發布日期的排序功能，以及分類瀏覽，是過去純靠名稱搜尋所沒有的發現機制。
影響範圍
Obsidian 目前有超過 1,500 款社群插件，插件生態的信任模型過去完全依賴開放原始碼本身的透明性與 GitHub 的人工審查，沒有系統性惡意程式偵測。這次的改動讓 Obsidian 的插件安全模型接近瀏覽器擴充套件商店（Chrome Web Store、Firefox Add-ons）的強制審核架構，但仍保留 GitHub 作為主要發行管道，維持與 OSS 生態的相容性。
原始來源：Obsidian Blog