译-我是怎么在项目中使用ES6模块化的
http://jsrocks.org/2015/05/how-i-m-using-es6-modules-in-production/原文链接
我使用ES6 modules工作已经有一段时间了，今天我就向大家分享下我是怎么使用ES6 moudule的。
首先，向大家介绍一下Babel ，Babel是用来JS转译的整合工具，它是一个非常活跃的项目，而且它几乎覆盖了所有现代JavaScript特征。（注：JS转译（Javascript Transpiler）请自行谷歌）
Babel完美支持模块化，你可以自己决定你代码的风格，你可以使用AMD,Common,UMD这些规范，而且你甚至能自定义模块规范。
在我的公司里，我们开发了一个基于AMD modules规范的框架（当然尚未开源），用来构建我们的应用。
相信我：对于开发大型的应用，使用AMD规范仍然是一个很好很好的解决方案。我们不能再把所有js代码反正一个文件里，这样是不行的。
悲剧的是我们现在很多些应用的解决方案是类似于Webpack,要想迁移到AMD modules可不是那么容易，而我们公司关于模块化的解决方案是很实用的（尚未开源）。
注：在本文中“解决方案”都是指JS模块化解决方案。
微模块策略
这个策略对我来说很有用。
正如我上文说的那样，我们最终产出模块必须要要是AMD module，但是当某一个AMD模块需要依赖其他模块时，我叫那个模块（AMD模块依赖的模块）叫做微模块。
微模块并不会被应用的每个模块都用到，但是利用它能帮助我们组织代码。
以下代码演示了我们怎么使用微模块：
微模块策略
这个策略对我来说很有用。
正如我上文说的那样，我们最终产出模块必须要要是AMD module，但是当某一个AMD模块需要依赖其他模块时，我叫那个模块（AMD模块依赖的模块）叫做微模块。
微模块并不会被应用的每个模块都用到，但是利用它能帮助我们组织代码。
以下代码演示了我们怎么使用微模块：
importconfig from'./config';//导入ES6模块import{ globalpkg } from'./config';//动态注入ES6模块参数importfactoryfrom'./factory'; zaz.use((pkg) => {"use strict"; config.dynamic.globalpkg = pkg; pkg.require(['modFactory'], (modFactory) => { modFactory.create(pkg.utils.deepMerge(config._static,factory)); }); });
我们在代码的顶部导入了一些模块，并且在我们的AMD模块里还使用了这些导入的模块。在其他的应用中并不会用到这些ES6模块，但是使用了这些微模块后，编译后产生的最终源码有更高的可读性。
这是config模块的代码：
constgithubURL ="OUR GITHUB URL HERE";conststaticServer ="http://s1.trrsf.com";consttestsPath =`zaz-${type}-${name}/tests/index.htm?zaz[env]=tests`;constname ="stalker";consttype="mod";constversion ="0.0.1";conststate ="ok";constdescription ="JavaScript API to deal with user data";letglobalpkg =null;// default exportconstconfig = { _static: { name, version, state, description, docs:`${githubURL}/pages/terra/zaz-${type}-${name}`, source:`${githubURL}/Terra/zaz-${type}-${name}`, tests:`${staticServer}/fe/${testsPath}`, dependencies: ['mod.wilson'] }};exportdefaultconfig;
这是项目的源码结构：
└── src ├── _js ├── config.js├── environment.js├── helpers.js├── factory.js├── methods.js└── mod-stalker.js└── mod-stalker.js
我把一些AMD模块的逻辑放进了微小的ES6模块里。
这对于构建处理是很简单的：Babel转译ES6的Javascript代码为ES5的代码；使用导入CommonJS模块的方式来导入微模块。最后用Browserify打包代码。
哈哈！最终生成的代码符合AMD模块规范了。
下一步
Sourcemaps比起Browserify来说，Sourcemaps不能很好的处理这个编译的流程。
也许这里能有更好的实现方式。
我们现在可以开始使用ES6新特征和模块化来重构我们的框架了。
你甚至可以自己实现模块加载规范给你的程序，但是我认为这可能不是一个好方法，有可能你会需要完全重写现有的模块加载系统。
结论
现在模块规范已经完成了，而且是非常成熟和有效的。
然而，web浏览器至今没有提供js模块加载的原生API,所有像AMD或者CommonJS就显得格外重要了。
现在我们已经体会到ES6模块语法的好处了，可以让我们的代码拥有更高的可读性和简洁性。
现有的工具，比如Babel和Browserify能减少我们开发的痛苦，相信在不久的将来等ES6普及后，我们就能简化js开发流程，这样就能舍弃这些构建打包工具了。