與AMD和CommonJS相比，UMD有什麼缺點？

01-11

最近使用Webpack，發現WebPack在組裝時可以選擇用哪一種模式來export當前的庫：
output.libraryTarget Which format to export the library: "var" - Export by setting a variable: var Library = xxx (default) "this" - Export by setting a property of this: this["Library"] = xxx "commonjs" - Export by setting a property of exports: exports["Library"] = xxx "commonjs2" - Export by setting module.exports: module.exports = xxx "amd" - Export to AMD (optionally named) "umd" - Export to AMD, CommonJS2 or as property in root
UMD這種定義Module的模式能同時兼容AMD，CommonJS規範，在沒有AMD和CommonJS的時候也可以正常使用，看起來似乎是一種完美的解決方案。與AMD和CommonJS相比，它有哪些缺點呢（貌似只是污染了全局命名空間?）？或者說，在什麼時候，不應該使用UMD呢？

「與蘋果、梨相比，{蘋果, 梨, 桃子} 有什麼缺點？」

代碼量更大

不請自來回答一下。

首先UMD是什麼，中文解釋就是通用模塊定義，兼容AMD，CommonJS和一般的全局定義。具體代碼可自行谷歌。

我為什麼會接觸到UMD，因為我寫的一個UI庫需要同時在AMD和CMD的環境下使用，所以接觸到了UMD，當然UMD是不支持CMD的，但這不就是加兩行代碼的問題嘛。

好處自不用說，一個文件能在多個環境下不用修改就可以使用。

但題主問的是缺點，那優點我就不說了。

1. 代碼量。兼容需要額外的代碼，而且是每個文件都要寫這麼一大段代碼。

2. 代碼合併。我沒試過用webpack去合併代碼，但明顯requireJS的方法是合不了UMD的代碼的。

在什麼時候不應該使用UMD呢，就是獨立項目里，一般獨立項目不會向外界提供API，所以一種模塊定義方法就好。如果是要做UI或SDK要用在多種環境下，可以選擇UMD，當然是選擇，但不一定只能UMD。其實還可以通過腳本打包的方式按需求打包成不同的模塊定義方式提供給其他人調用，這樣可以減少代碼，應該也可以順利地合併了

好了，目前就這幾個問題，希望有更多的人補充。

比所謂的CMD不知道到高到哪裡去了