5種前端代碼共享方案：npm包、git submodules、腳手架模闆生成、複制、UMD或子產品聯邦

背景

我獨立開發了《聯機桌遊合集》，是個網頁，可以很友善的跟朋友聯機玩鬥地主、五子棋、象棋等遊戲。這些遊戲是不同的前端項目，而這些項目有很多公共依賴，我是如何管理的呢？是如何做方案選型的呢？

今天，我先介紹5種前端代碼共享方案，我使用的方案就是從這5種中選擇的2種。這五種包括：

• npm包
• git submodules
• 腳手架模闆生成
• 複制
• UMD或子產品聯邦

npm包

被共享的代碼作為npm包，由引用方通過​

​npm install​

​安裝。

特點

1. 因為給個名字和版本号即可被安裝，而且文檔可以挂在npm網站（或公司内網鏡像npm網站）上，是以适合跨團隊、跨組織協作。
2. 暴露的是打包後的代碼，篡改成本較大，通常認為引用方不會修改源碼。
3. 開發者主要靠文檔了解API，無需關注源碼。
4. 有版本管理機制，各個引用方可以按需更新。

适用場景

1. 跨團隊、跨組織協作。
2. 有完善的使用文檔。

誤區

很多人認為，自己開發都是私有庫，是不是不能用npm了？你可能以為npm必須釋出到公開的，才能用。

其實不是這樣的，npm也可以從git倉庫安裝依賴。你可以不釋出到npm，也可以隻把産物（或源碼）上傳git倉庫。

是以個人開發者也能用npm，隻是我認為效率不高罷了，不如直接用 git submodules。

git submodules

我在文章《Git Submodules 介紹（通俗易懂，總結了工作完全夠用的 submodule 指令）》詳細介紹了 Git Submodules，強烈建議閱讀。

特點

1. 因為暴露的是源代碼，引用方必須有子子產品的讀權限，是以适合團隊内、組織内協作或個人開發。
2. 通常允許引用方開發者修改子子產品代碼，并送出。修改子子產品代碼的成本較低。
3. 開發者主要靠閱讀源碼了解API和機制。
4. 有版本管理機制，各個引用方可以按需更新。

适用場景

1. 團隊、組織内部協作。
2. 引用方時常需要修改共享代碼。

腳手架模闆生成

舉個例子，​

​create-react-app​

​​、​

​vite​

​等都有一些初始化項目的模闆。其實大多數前端項目都是以這些模闆為起點，逐漸疊代。而且很多公司都有自己的項目腳手架，有自己的獨特的模闆。這些模闆，也屬于是代碼共享方案。

特點

1. 暴露的是源代碼，開發者需要閱讀源代碼。
2. 腳手架可能會預先安裝一些依賴，這些依賴是npm包，開發者需要閱讀腳手架文檔來了解。
3. 代碼生成後，代碼全放在引用方的倉庫裡，開發者可能随時修改檔案。是以，腳手架模闆更新時，項目更新難度相對較高。因為原始模闆檔案可能已經被改的面目全非了。

注意，使用腳手架模闆需要謹慎。你每釋出的一個版本必須是長期可用的、或者更新成本極低的。這并不容易，我之後會發文章詳細聊聊，如何做好「腳手架模闆生成」。

适用場景

1. 架構腳手架（能夠保證所有版本的模闆都長期可用）。
2. 有一些由模闆方維護的檔案不允許引用方修改（保證更新成本低，可以通過自動化方式更新模闆）。

複制

特點

1. 暴露的是源代碼，開發者需要閱讀源代碼。
2. 通常複制的代碼不會太長，隻是一些簡單的函數。
3. 沒有版本管理機制，當複制的源頭更新後，你可能感覺不到源頭的更新，也可能你對源碼做了修改，是以始終處于舊的版本。

适用場景

1. 某個npm包沒有做按需加載，但你隻需要引用一小部分功能。
2. 引用的代碼，已經非常穩定，不必更新，或者沒有跟源頭保持同步的訴求。

UMD或子產品聯邦

特點

1. 暴露的是打包産物，是以開發者需要閱讀文檔了解API。
2. 開發者篡改成本較高，通常認為不會去修改它。
3. 有版本管理機制，可以通過url指定具體版本号，做到按需更新。也可以使用某個latest的URL，始終保證擷取到最新的版本。
4. 基于浏覽器緩存機制，可以降低公共資源的重複加載。

适用場景

1. 需要自動保持最新版本，且100%相信維護團隊。可以使用latest url。（這樣每次更新時無需主動釋出）
2. 減少公共資源的重複加載，提高使用者體驗。

我的選擇

1. 我是個人開發者，是以我放棄了npm包，選用了git submodule。
2. 我确實有一些不同的項目，需要統一的初始化模闆，是以選用了腳手架模闆生成。而且我有明确的疊代更新腳手架模闆的方案。
3. 我不需要複制。
4. 雖然我有一些公共依賴，但是使用者加載時間已經很短了，我的資源體積并不大，加載時間不是我的痛點，是以我沒有選用UMD、子產品聯邦。

寫在最後