在前段时间，我把之前写的几个package重新命名为hello开头的包，例如hello-storage, hello-events, hello-worker，这些包非常基础，不依赖任何第三方包，就是用基础的api来实现的，因此，代码非常简单。面对这种随即编写，随即打包发布的package，我采用最小化的方式进行发布。
一个包，在发布的时候，其实最重要的是考虑用户（开发者）使用这个包的使用场景，如果不考虑，直接给源码就行了，干嘛还要进行构建发布呢？所以，对于我而言，主要考虑两点：
- 模块化
- 代码兼容性
-
模块化是指用户可能在不同的模块规范下使用你的包，目前而言，有amd, cmd, commonjs, es6 module这几种，另外，还要考虑在浏览器中直接使用<script>标签引用脚本（没有模块化环境）。针对这点，我采用umd的方案，但是代码是自己写的，我的源码是es6 module，因此在导出的时候使用export default，但是在其他模块化规范下，并不需要default这样的接口，因此要直接export整个模块，因此，我的方案就是，对于要直接引用es6模块的用户，建议他import源码文件，而其他模块化规范下，引用dist文件：
// ES6
import HelloEvents from 'hello-events/src/hello-events'
// CommonJS
const HelloEvents = require('hello-events')
// 由于webpack在打包时能正确处理export default的问题，因此如果使用webpack，可以
import HelloEvents from 'hello-events'
对于开发者而言，这种解释应该是非常容易理解的。使用习惯上也不会造成困扰。那么怎么来实现这套方案呢？我在代码中采用umd的方案实现：
!function(root) {
// ES6代码转码之后放在这里
if (typeof define === 'function' && (define.cmd || define.amd)) { // amd | cmd
define(function(require, exports, module) {
module.exports = HelloEvents;
});
}
else if (typeof module !== 'undefined' && module.exports) {
module.exports = HelloEvents;
}
else {
root.HelloEvents = HelloEvents;
}
} (this || window);
这得益于我以前写过omd.js。那怎么才能最终输出上面这个结构呢？我使用了gulp来做，并用上了我写的gulp-bufferify包来实现文件内容的修改。这样，当我使用babel把es6的代码转化为es5的代码之后，再对文件内容进行修改，就能得到上面这个结构了。
-
代码兼容性是指要考虑在不同浏览器版本中代码都能跑，主要是指一些es6新特性的降级，例如async函数。因为我写的这些pacakge的功能非常弱，不会涉及generator函数，也不会涉及symbol，因此其他大部分功能都可以用es5语法代替，并且找到对应的babel插件即可。
对于我而言，主要考虑到两个点：1.class语法；2.async/await语法；3. ...语法。这三个语法已经是我日常写作的必须品，因此在我的构建脚本里面，首先需要将这三个语法转化为es5语法。1和3使用babel-preset-env就可以自动解决，非常好用，2的话我使用了bebel-plugin-async-to-promises，它可以将async/await语法转换为promise，而preset-env默认使用bebel-plugin-transform-async-to-generator（将async/await语法转换为generator语法）和bebel-plugin-transform-regenerator（使用一个特殊的变量regeneratorRuntime来支持generator语法，这个变量需要你引入babel-polyfill），这两个插件和bebel-plugin-async-to-promises有冲突，因此要禁用默认选项，在.babelrc里面这样写：
{
"presets": [
["env", { "exclude": ["transform-async-to-generator", "transform-regenerator"] }]
],
"plugins": [
"async-to-promises"
]
}
但是，其实这里对于开发者而言，是需要进行权衡的，比如说，我会在代码中随意使用array.filter, Object.assign等，这些新接口是es6新加入的，对于老版本的浏览器是不支持的。但是这些接口不会被babel转译，因此，我也不会特意在自己的代码中去实现这一块。之所以不自己在代码中实现这块，是因为这种接口很大程度上其他包也会用。对于使用包的开发者而言，他需要自己进行权衡，是不是要引入一个polyfill，如果他自己不想支持低版本的浏览器，就不用引入了。这样，可以保证我自己的包里面的代码是绝对干净，但是在大部分情况下是可以运行的。
但是这里有一个问题，就是为什么不把async/await也留给上层的开发者自己去决定。这是因为这个语法没有办法用polyfill，你不可能通过一个polyfill让一个不支持async语法的浏览器变得支持。这就是权衡，如果我在自己的所有包里面都把这两个语法的转译代码写进去，那么最后，上层开发者的应用里面，就会有重复代码，这也是没有办法的，如果webpack等打包工具更加智能，就可以将这些重复代码提升作用域来实现减少重复的效果。
-
上面讲完了我所关心的两个点之后，下面要出代码了。不过别急。我们再讨论一个问题，就是有没有必要任何包都用webpack？答案显而易见，我现在开始不大喜欢webpack，我越来越觉得webpack应该是一个应用层面进行打包时才用的上的工具，对于一个package而言，不应该进行打包，而是以原始的module文件间引用关系对外使用，只不过需要做上述两个点的处理。
好了，上代码：
// 安装对应的npm包 $ npm i -D babel-core babel-plugin-async-to-promises babel-preset-env gulp gulp-babel gulp-bufferify
// 构建脚本 build.js
var gulp = require('gulp')
var bufferify = require('gulp-bufferify').default
var babel = require('gulp-babel')
var namespace = 'HelloWorker' // 修改为自己的ClassName，一定要跟源码里面的class名对应
var entryfile = 'src/hello-worker.js' // 修改为自己的入口文件
gulp.src(entryfile)
.pipe(babel())
.pipe(bufferify(function(content) {
content = content.replace(/Object\.defineProperty\(exports,[\s\S]+?\);/gm, '')
content = content.replace(`exports.default = ${namespace};`, '')
content = `
!function(root) {
${content}
if (typeof define === 'function' && (define.cmd || define.amd)) { // amd | cmd
define(function(require, exports, module) {
module.exports = ${namespace};
});
}
else if (typeof module !== 'undefined' && module.exports) {
module.exports = ${namespace};
}
else {
root.${namespace} = ${namespace};
}
} (this || window);
`
content = content.trim()
content += "\n"
return content
}))
.pipe(gulp.dest('dist'))
// 进行构建 node build.js
这段构建脚本非常简单，稍微花点时间就读懂了。根据自己的实际情况进行修改，比如路径问题，比如namespace那个地方。总之对于我自己而言，非常简单的包都会采用这样的模式去做。
