這兩天一直在忙於封裝乙個vue table元件並發布到npm，記錄一下我是如何把npm包的大小從100多kb減小到不足1kb的過程。
這個元件底層依賴於element-ui，使用了其table元件和pagination元件，最終的元件是乙個完全通過配置來描述每一列的**元件。最開始我發布的是打包之後的**。如果使用的這個元件的專案中沒有引入過element-ui元件，那麼不會造成任何重複的依賴，直接引用打包後的版本。但是如果專案本身已經引入了完整的element-ui(我們公司使用這個元件的10餘個系統均引入了完整的element-ui)，那麼很明顯會造成**的重複，會使bundle增加90kb(未壓縮時)。
如果發布的經過打包後的元件，是沒辦法避免重複依賴的。如果可以像把源**直接copy到專案再import引入這樣，就可以避免重複的依賴了。這個可以使用package.json中的module欄位來完成。
當package.json中存在module欄位時，會優先尋找module對應的檔案，並使用es模組規範處理。
我們可以把未經過打包的源**發布到npm，並把package.json中的module欄位指向源**，這樣引入的package就交由專案的構建工具（webpack, babel）來進行處理，因此理論上就可以避免重複依賴了。
有可能，因為webpack外掛程式可以配置exclude欄位，如果專案的webpack配置exclude掉了node_modules，就會產生***。比如可能未經babel轉碼成es5**（我發布的這個元件目前只會存在這樣一種可能的***）。
babel轉碼後再發布
在readme中指出，讓使用者取消掉babel的exclude
到目前為止，還並不能解決重複依賴的問題。。。這是因為重複依賴的判斷機制.node.js中相同模組是否會被載入多次？
nodejs是根據模組的路徑來判斷是否為同一依賴的，而大家都知道node.js會從當前模組所在目錄的node_module開始找起，如果沒找到再會去找上級目錄的node_modules，直到根目錄為止。那麼問題就來了。
方法1，在專案的babel配置中新增按需引入element-ui的配置，但是這個方法需要修改專案的配置，比較繁瑣，我維護的10來個系統需要乙個乙個去改，太麻煩了。。。。
不過這樣也造成了一定的問題，那就是本身不使用element-ui的專案需要手動引入打包之後的發布的檔案。不過不使用element-ui元件的專案使用這個**元件的收益和概率都不高，如果真的要用的話，單獨再發布乙個完全打包之後的包，也能快速解決問題。
通過這兩天的折騰，主要收穫有4點
1、發布npm包的流程
2、package.json中的module欄位
3、判斷重複依賴的機制
4、基於ui元件封裝元件時如何避免重複依賴
發布npm包到github packages
github 推出 github package registry 後，提供了軟體包管理服務，開發者通過它可發布公共或私有軟體包。對於開發人員來說非常的方便，目前支援許多大家都比較熟悉的包管理工具，如 預設情況下，github packages在您在package.json檔案的name欄位中指定的...
前端元件包發布到npm私服
前端元件包發布到npm私服，前端小白親自實踐 三 總結 對個人來說，我們寫的包往哪兒發布，無非下面三個地方。其中 映象倉庫每隔十分鐘會同步一下 npm 倉庫的新模組，所以實際要看的也就是往 npm 倉庫和公司內部搭建的私有 npm 倉庫上如何發布包。3 公司內部私有 npm 倉庫 有的公司內部開發一...
npm包從構建到發布流程
使用npm init初始化專案目錄 檢視npm源位址 如果不是如圖所示的官方源位址，需要使用如下命令設定為官方源位址 npm config set registry然後登入你在npm官網註冊的賬戶，沒有註冊的直接前往npm官網註冊，註冊完使用如下命令進行登入，輸入賬號密碼以及乙個用於接收郵件的郵箱即...