Hilshire
commented
5 years ago 尝试抽取业务组件
想把不同项目可以共用的组件抽取出来，发到公司的npm镜像上。能发包的组件，和项目里的业务组件，要求本身就不一样——不如说正确的发包本身就是一种要求。
抽象的方式是建立一个项目提供一个基本的壳然后一点点放进去。没什么太大意义但是玩一玩还不错。
rollup 和 babel
按照Publishing NPM package with Rollup, Babel, Flow, Jest and ESLint 进行了配置然后发现测试代码没有被编译。测试代码：
let a = 1;
new Promise((resolve, reject) => {
setTimeout(() => resolve(a), 0);
})顺便一体如果没用到 a 这边变量，上面的赋值语句会被处理掉。
然后发现这篇文章已经有一点过时了，babel 现在把包放在 @babel 域下，所以安装的包也发生了变化。 babel-core -> @babel/core babel-preset-env -> @babel/preset-env 修改之后顺利编译，但是Promise没编译，可能要手动加垫片。不过好麻烦，先放着吧。 最后的结果：
var a = 1;
new Promise(function (resolve, reject) {
setTimeout(function () {
return resolve(a);
}, 0);
});
//# sourceMappingURL=index.esm.js.map@babel/plugin-transform-runtime 和 @babel/plugin-external-helpers
稍微有点规模的 rollup 配置一般都能见到这两个东西，那么它们是什么呢？ 其实官网上就有介绍 @babel/plugin-transform-runtime 它干了两件事：
- 把babel依赖的帮助函数集合起来
Babel uses very small helpers for common functions such as _extend. By default this will be added to every file that requires it...This is where the @babel/plugin-transform-runtime plugin comes in: all of the helpers will reference the module @babel/runtime to avoid duplication across your compiled output. The runtime will be compiled into your build.
- 防止
@babel/polyfill和 提供的内建函数污染全局作用域Another purpose of this transformer is to create a sandboxed environment for your code. If you use @babel/polyfill and the built-ins it provides such as Promise, Set and Map, those will pollute the global scope...he transformer will alias these built-ins to core-js so you can use them seamlessly without having to require the polyfill.
不过看上面的东西就要搞懂做了什么事很难的，所以找了另一篇文章： 一口（很长的）气了解 babel 这样就差不多了 还想了解就再看这个： 你真的会用 babel 吗？ 羡慕大佬的博客
要注意 @babel/plugin-transform-runtime 是运行时使用的依赖，对应的@babel/runtime 需要放在 dependencies 而不是 devDependencies 中（这一条存疑，希望有人能指教一下）
做好之后 Promise 会变成从 corejs 中引入的模块
import _Promise from '@babel/runtime-corejs2/core-js/promise';
之后发现这样配出来的 rollup 是不能编译 requrie 的。
emm... 我选择webpack
依赖问题
项目使用的是 iview@2.5.3，由这个项目抽出来的业务组件也必然依耐 iview
如果按照通常的方式，让项目依赖 iview， 会导致如果要使用组件库，就要安装 iview . 如果版本相同还好说，版本不同就会单独安装一个不同版本的 iview，这显然是不可接受的。做成这样的话就无法对外提供服务了。
不过 npm 管理依赖的方式很全面。除了开发常见的 dependencies 和 devDependencies 之外，还有 peerDependencies
dependencies： 指定项目运行时所依赖的模块 devDependencies： 指定项目开发时所需要的模块 peerDependencies：指定当前模块所在的宿主环境所需要的模块及其版本 谈谈npm依赖管理
更全面的包管理可以看这里：你需要知道的几类npm依赖包管理
可以看一下 html-webpack-plugin 的 package.json ，可以看到它就是用 peerDependencies 指定了插件依赖 webpack 的。安装这个插件不会安装 webpack ，但是如果你的项目中没有 webpack 会导致报错。
看一下 package.json 的文档，大部分人都会惊讶 package.json 提供了这么多选项。
发布轶事一则
0.0.1 版本完成之后，理所当然的要发到公司的 npm 镜像上。然而公司的 npm 镜像功能一直奉欠，这让我十分难受。我那个组件库名字叫 canon ，这确实是一个很容易想到的名字， npm 上也确实有一个包叫 canon 。
一般来说，这样的包是发不上去的，我是这么想的。然而实际上发布成功了，我上镜像上一查，就找到了那个同名的包。镜像把我的推送合并到那个包里去了。
如果 canon 的作者看到，必然会满脸问号吧。
于是给自己的包加了个域。之前的 gitlab 群组取名非常随意，唤作： frostmourne 。于是，公司 npm 镜像的域里面多了一个 frostmourne scope，里面有一个叫 canon 的项目。
嗯， Lich king 想不到还是个音乐爱好者哩。
关于 scope 相关在这里可以查到： npm - 参考手册
回归 rollup
在使用 webpack 之后，项目变得顺风顺水起来。然而，当我把包发到 npm镜像之后，有一个问题等待着我。 export default 的对象没有被引入，引入的是一个空对象。
// canon/src/index.js
export default {
version: '0.0.1',
install,
...
}// test-canon-pkg/src/main.js
import canon from '@frostmourne/canon';
console.log(canon); // {}在网上搜索了一下，得到了这个解释：https://stackoverflow.com/questions/44541561/webpack-output-is-empty-object
于是按照上面的修改配置，成功解决问题。
...
output: {
path: path.resolve(__dirname, '..', 'dist'),
filename: 'index.js',
library: 'canon',
libraryTarget: 'umd',
},
...之前一直在想为什么写轮子的时候偏向 rollup 呢？原因很简单，它从一开始的出发点就是这个！而 webpack 的出发点是 web app ，这导致两者的侧重点不同。
比如对 webpack 来说 code split 是最重要的功能之一，以至于在 webpack4 直接从插件集成到配置里。而对 rollup ，把代码打包成单个文件时合适的。这些细节会一点点体现出来。
这样一来，这个项目应该用 rollup 打包。我还得把它请回来。
不过也不会 remove webpack 。和众多组件库一样，canon 有自己的介绍页。这一部分需要 webpack 。
工具本身并不重要，重要的是在合适的场合使用合适的“锤子”。
第一次 pr
然后被拒了。这pr确实比较水，也算是意料之中。不过即使只是提一个pr也是有门槛的。
pr是一个工作流的问题。这里有两篇不错的文章，而我不打算再出篇幅说这个。其中的 git 操作本身就是开发应该掌握的知识，每一步的原因也很明了。和常见的工作流相比，多了一步 fork 和 pr 本身而已。而解释其后工作流相关内容，已超出我的能力。我对工作流并无深刻的见解，恐怕不能写的比这两篇文章更好。所在团队的项目也不太可能基于同样的工作流。
不过其它部门也确实有使用 pr 的项目，我至今才知道其中的意义，而项目的建立者时候并没有向其它人科普的打算。对于老师，也要有学生才行吧。
GIT团队合作探讨之二--Pull Request 3.3 创建 Pull Request
成果
项目中独立于业务的公共组件单独提取成了一个 npm package，之后有适合做成公共组件的就在 canon 里迭代。业务组件与项目分开，其它项目可以方便的引用。
同时，团队成员在写组件时要考虑之后可能会放到 canon 之中，组件变得更加纯粹。
而 canon 本身的发展也可以促进团队的进步，如何写好一个组件库是一个很讲究的事情。关于canon，也许写在另一个commet里比较好。
有时真会让人觉得不如想办法装一个
刚进公司写的项目竟然迭代了两年，是该重构一下升个级了。开个贴记录一下吧。
eslint-plugin-html -> eslint-plugin-vue
V2版本的 vue-cli 使用的还是 eslint-plugin-html，之后才升级成 eslint-plugin-vue 升级了 eslint 版本之后，较低版本的 eslint-plugin-html 报错了
详见 eslint-plugin-html error: It seems that eslint is not loaded. Compatibility with ESLint 4