npm v12 即將到來的重大破壞性變更：安裝腳本預設停用與依賴來源授權機制
GitHub Changelog · 2026-06-09
GitHub 於 2026 年 6 月 9 日發布公告，說明 npm v12 預計於 2026 年 7 月正式釋出，其中包含多項影響安裝行為、依賴解析與指令輸出格式的破壞性變更。最核心的改動是預設關閉安裝腳本執行，旨在從根本上縮小供應鏈攻擊的攻擊面。這些變更已於 2026 年 2 月的腳本安全性正式發布公告中預告部分內容。
核心改動：安裝腳本預設停用
allowScripts 設定在 npm v12 中預設為關閉，這意味著套件的 preinstall、install 與 postinstall 生命週期腳本將在未明確授權的情況下不再自動執行。受影響範圍包括 git 依賴、本地檔案連結（file/link）以及原生模組的建置腳本（如 node-gyp 觸發的 prepare 腳本）。
配合此變更，新增的 npm approve-scripts 指令允許開發者明確審核並許可特定套件執行腳本。基本用法如下：
# 審核並許可全部已安裝套件的腳本
npm approve-scripts --all
# 許可特定套件（預設鎖定版本）
npm approve-scripts canvas sharp
# 僅列出待審核的腳本（不修改設定）
npm approve-scripts --allow-scripts-pending搭配使用的還有 npm deny-scripts，用於明確撤銷某套件的腳本執行權限。--allow-scripts-pin 選項預設為啟用，表示授權會綁定至特定版本，升級後需重新審核。
依賴來源授權機制
除了腳本安全性之外，npm v12 另引入兩個新的預設限制，以控制依賴的解析來源。--allow-git 預設值改為 none，無論是直接或間接的 git 依賴，安裝時均需透過明確旗標授權，藉此關閉先前存在的任意程式碼執行風險。
同樣地，--allow-remote 亦預設為 none，凡透過 HTTPS 等遠端 URL 指定的 tarball 依賴，必須在安裝指令中加上對應旗標才能解析。使用 git 或遠端 URL 依賴的專案在升級至 v12 前，需檢視 package.json 中的依賴宣告並更新 CI 流程。
其他破壞性變更
npm v12 亦包含多項較小但同樣具有實際影響的調整：
npm-shrinkwrap.json停止載入：此檔案不再被讀取或生效，應重新命名為package-lock.json，或改用bundleDependencies。npm view --json輸出一致化：輸出格式統一為陣列，消除原先因查詢單一欄位時回傳純字串的不一致行為。- Man page 系統登錄移除：系統層級的
man頁面不再安裝，需改用npm help <command>。 star/stars/unstar指令移除：這些指令已從 CLI 中刪除，不再提供任何功能。npm adduser行為變更：帳號管理移至 npm 網站，CLI 端僅保留npm login。- SBOM 套件名稱來源變更：
npm sbom --sbom-format=cyclonedx現改從package.json讀取元件名稱，而非磁碟目錄名稱。 - Node 路徑解析改用
process.execPath：移除透過PATH環境變數查找 node 的whichnode機制。 - 使用者 Profile 欄位移除：npm registry 使用者資料中的 Twitter 與 Freenode 欄位已刪除。
社群討論可參考 GitHub 官方 community discussion #198547。
原始來源：GitHub Changelog — Upcoming breaking changes for npm v12
靜態型別與鏟子：程式語言設計中的型別系統剖析
carefully.understood.systems · 2026-06-10
2026 年 6 月 10 日，carefully.understood.systems 發表一篇以「鏟子」為比喻的文章，探討靜態型別系統在程式語言設計中所扮演的角色，以及工具性與表達性之間的根本張力。文章從語言設計者的視角切入，分析型別系統究竟是讓開發者更有效率地「挖掘」問題，還是反而製造阻力。
核心論點：型別系統的雙重性
靜態型別系統本質上是一種預先約定（upfront contract），能在編譯階段捕捉錯誤，但這個優勢的代價是開發者必須在設計初期就表達清楚意圖。就像鏟子挖掘前需要先定義挖掘位置，型別宣告要求程式設計師在尚不確定需求的探索階段就做出決策。
文章進一步指出，現代型別推論（type inference）雖然降低了手動標注的負擔，但並未從根本上解決「探索性程式設計」與「型別安全」之間的矛盾。漸進式型別（gradual typing）在 TypeScript、Python 等語言中的實踐，是目前業界折衷兩者的主流策略。
影響範圍
此類關於型別系統哲學的討論，直接影響前端工程師在選擇工具時的判斷。TypeScript 的 strict: true 模式與「漸進遷移」之間的抉擇，在實際專案中仍是常見的工程決策點。文章提供了一個有助於理解這個抉擇背後邏輯的框架。
原始來源：carefully.understood.systems — Static types and shovels
HTML 優先策略如何讓網站用戶數在一夜之間翻倍
mohkohn.co.uk · 2026-06-11
2026 年 6 月 11 日，開發者 Mo Hkohn 發表實際案例報告，說明將網站架構從 JavaScript 重渲染模式切換為 HTML 優先（HTML-first）設計後，使用者數量在短時間內顯著成長。文章以第一人稱描述重構過程與關鍵決策，並聚焦於語意化標記對搜尋可見性與載入效能的影響。
核心改動：回歸語意化標記
所謂 HTML 優先策略，指的是優先以原生 HTML 元素與語意標籤（如 <article>、<nav>、<main>）構建頁面結構，而非依賴 JavaScript 框架在客戶端動態生成 DOM。這個方向與近年來 Astro、Enhance 等框架倡導的「islands architecture」理念相呼應，核心原則是讓瀏覽器處理它本身擅長的事。
在技術執行面，HTML 優先通常意味著減少不必要的 JavaScript bundle、利用瀏覽器內建表單行為、以及讓搜尋引擎爬蟲能直接讀取完整頁面內容而無需執行 JavaScript。首次內容繪製（FCP）與累積版面位移（CLS）是最直接受益的兩個 Core Web Vitals 數值。
影響範圍
案例中提到的用戶翻倍現象，作者將其主要歸因於搜尋引擎排名改善後帶來的自然流量增長，而非單純的效能優化。這與 Google 對 JavaScript 渲染頁面的索引延遲問題直接相關。對於以內容為主的網站，HTML 優先架構提供了一條具體可行的路徑，在不大幅增加開發複雜度的前提下同時改善 SEO 與使用者體驗。
原始來源：mohkohn.co.uk — Building an HTML-first site doubled our users overnight