關於我與前端無關緊要的分享 Day 51

JavaScript 發跡後發展多年，直到 Nodejs 才真正模組化的實作誕生，那是一個有點像 Function 的一個堵塞請求，讓垮檔案變得可以被溝通。大家熟悉的那 require 就是 CommonJS 的語法，從 webpack 時代一點一滴深植在開發者的底層知識中。

ESModule 統一之前，CommonJS 的生態有多深

時至今日的前端開發已經很習慣所謂的模組化開發，但過去模組化迎來 ESModule 的統一之前，其實還是爭亂不休。特別是 Nodejs v8.5.0 的實驗性支援開始，歷經迭代變革，如經的 nodejs 可以直接透過設定 type: “module” 支援 ESM 的運行。但多年的 Nodejs 所建構的 CommonJS 生態還真不是說假的，事到如今 Nodejs Default Runtime 依然是 CommonJS。而過去龐大生態系重度依賴的包含 webpack, jest, storybook 等等多年的老工具都是預設支援 CommonJS，而對於 ESModule 的運行基本上存在龐大的問題。

到達現今，有一層 TypeScript作為抽象介面，打包後有 rebuild, rollup, vite 等等工具生態可以多輸出不同環境的打包，但現今並不是每一個 npm package 都知道要支援完善，有的是設定問題還後多疑慮。除此之外，還有可怕的 npm system 複雜的 dependency architecture，真的是坑山滿滿。

轉換工具解決不了 CJS 與 ESM 的不對等

當然你會覺得使用一下轉換工具就好，但事實上並不是這麼單純的事情。CommonJS 和 ESModule 是天生不對等的兩種實作，只能做到極其相似，但依然是不等價。所以即使 ESModule 誕生多年，仍然有無數的開發者卡到對應的實作行為，沒辦法正確去處置它。甚至是編譯過關，實際運行卻會報錯。而且現今的 Builder Tool Runtime 也並非都是基於 ESModule 去運行，而是各自跑各自的。Dev Server 一套，Test Runner 一套，UI Peview Tool 一套，各自有各自的 Config 去管理運作，為了一致就費盡心思。加上每一套 Library 也不保證同時去支援 CommonJS、ESModule，不是要避開使用，就是要自己去過一層轉換或 mapping，甚至你覺得理所當然要支援的其實都沒有。這些龐大的問題體系在一般的 application 開發未必會讓你遇上，但你開始擴大應用的複雜度與規模，這些問題才慢慢浮上水面。

這塊的資料少到連 LLM 也幫不上忙

即使 AI 時代 ，LLM 可以從過去的歷史資料庫及網路上的文章尋找答案，但資訊可以說是少之又少，也極其缺乏系統化的教學，多半還是開發者自己學習多。包含有優化技巧、架構技巧、自動化搭建方案、Dev Config 環境隔離、相關的底層套件抽象… 等等龐大的資訊量。這些知識點真不是隨口兩句用什麼工具就可以全數解決，這些也都是透過無數的時間踩坑克服，參透原理。並不是「因為 AI 說這樣就可以解決」而胡亂加上看不懂的設定，而是透過龐大的知識疊加而透徹每一個環節的運行理念。

只能說我獨自在這塊花了好多精力學習這些知識，但真要說多少人需要？有多少人想優化？我想是微乎其微吧。