如果有一天自己用typescript 寫一個庫，或者插件，或者在使用一個架構和庫的時候，如果去看它的聲明檔案或者自己去定義聲明檔案。第一步，先認識前端現有的幾種子產品化方式。
1.認識js子產品化的幾種方式
使用方法及其源碼來識别庫的類型。 根據庫的文檔及組織結構不同，來判斷
全局庫 ：許多庫都是簡單的暴露出一個或多個全局變量。目前，大多數流行的全局通路型庫實際上都以umd庫的形式進行書寫（見後文）。 umd庫的文檔很難與全局庫文檔兩者之間難以區分。 在書寫全局聲明檔案前，一定要确認一下庫是否真的不是umd。
由于把一個全局庫轉變成umd庫是非常容易的，是以很少流行的庫還再使用全局的風格。 然而，小型的且需要dom（或 沒有依賴）的庫可能還是全局類型的。
子產品化庫
許多流行的node.js庫都是這種子產品化的，例如express，gulp和 request。
umd
umd子產品是指那些既可以作為子產品使用（通過導入）又可以作為全局（在沒有子產品加載器的環境裡）使用的子產品。 許多流行的庫，比如 moment.js，就是這樣的形式。 比如，在node.js或requirejs裡，你可以這樣寫：
然而在純淨的浏覽器環境裡你也可以這樣寫：
umd子產品會檢查是否存在子產品加載器環境。 這是非常形容觀察到的子產品，它們會像下面這樣：
如果你在庫的源碼裡看到了typeof define，typeof window，或typeof module這樣的測試，尤其是在檔案的頂端，那麼它幾乎就是一個umd庫。
大多數流行的庫現在都能夠被當成umd包。 比如 jquery,moment.js,lodash和許多其它的。
es6 子產品化
曆史上，javascript 一直沒有子產品（module）體系，無法将一個大程式拆分成互相依賴的小檔案，再用簡單的方法拼裝起來。其他語言都有這項功能，比如 ruby 的require、python 的import，甚至就連 css 都有@import，但是 javascript 任何這方面的支援都沒有，這對開發大型的、複雜的項目形成了巨大障礙。
commonjs用于伺服器，amd用于浏覽器。es6 在語言标準的層面上，實作了子產品功能，而且實作得相當簡單，完全可以取代 commonjs 和 amd 規範，成為浏覽器和伺服器通用的子產品解決方案。
es6 子產品的設計思想是盡量的靜态化，使得編譯時就能确定子產品的依賴關系，以及輸入和輸出的變量。commonjs 和 amd 子產品，都隻能在運作時确定這些東西。比如，
上面代碼的實質是整體加載fs子產品（即加載fs的所有方法），生成一個對象（_fs），然後再從這個對象上面讀取 3 個方法。這種加載稱為“運作時加載”，因為隻有運作時才能得到這個對象，導緻完全沒辦法在編譯時做“靜态優化”。
es6 子產品不是對象，而是通過export指令顯式指定輸出的代碼，再通過import指令輸入。
二、amd，cmd,commonjs 三種子產品化的代碼風格
require.js （amd） 子產品化加載
amd，即 (asynchronous module definition)，這種規範是異步的加載子產品，requirejs應用了這一規範。先定義所有依賴，然後在加載完成後的回調函數中執行：
具體可參考https://www.runoob.com/w3cnote/requirejs-tutorial-2.html
代碼書寫方式
commonjs
node 應用由子產品組成，采用 commonjs 子產品規範。 具體可參考
http://javascript.ruanyifeng.com/nodejs/module.html
cmd(sea.js)
具體可以參考
https://www.zhangxinxu.com/sp/seajs/docs/zh-cn/module-definition.html
es6 的import 和export
其它的書寫方式可以參考
https://es6.ruanyifeng.com/#docs/module#export-%e5%91%bd%e4%bb%a4
參考
四、認識umd
（1）是什麼（解決什麼問題，及應用場景）
umd 叫做通用子產品定義規範（universal module definition）它可以通過運作時或者編譯時讓同一個代碼子產品在使用 commonjs、cmd 甚至是 amd 的項目中運作。未來同一個 javascript 包運作在浏覽器端、服務區端甚至是 app 端都隻需要遵守同一個寫法就行了
(2) 代碼結構
（3）手寫一個例子
1.建立一個umd-module.js
2,挂載在window上的情況