与AMD和CommonJS相比,UMD有什么缺点?[摘录]

原创 pvfhv 教程 项目积累 192阅读 2017-06-29 19:54:18 举报

最近使用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的时候也可以正常使用,看起来似乎是一种完美的解决方案。
首先UMD是什么,中文解释就是通用模块定义,兼容AMD,CommonJS和一般的全局定义。具体代码可自行谷歌。我为什么会接触到UMD,因为我写的一个UI库需要同时在AMD和CMD的环境下使用,所以接触到了UMD,当然UMD是不支持CMD的,但这不就是加两行代码的问题嘛。好处自不用说,一个文件能在多个环境下不用修改就可以使用。但题主问的是缺点,那优点我就不说了。1. 代码量。兼容需要额外的代码,而且是每个文件都要写这么一大段代码。2. 代码合并。我没试过用webpack去合并代码,但明显requireJS的方法是合不了UMD的代码的。在什么时候不应该使用UMD呢,就是独立项目里,一般独立项目不会向外界提供API,所以一种模块定义方法就好。如果是要做UI或SDK要用在多种环境下,可以选择UMD,当然是选择,但不一定只能UMD。其实还可以通过脚本打包的方式按需求打包成不同的模块定义方式提供给其他人调用,这样可以减少代码,应该也可以顺利地合并了。
https://github.com/kalcifer/webpack-library-example

评论 ( 0 )
最新评论
暂无评论

赶紧努力消灭 0 回复