记一次被迫开发Egg插件的体验
# 为什么要开发egg插件
在日常的开发中我们总是需要借助npm资源(轮子)来满足我们的业务需求，如果你刚好是node开发者的话，那么恭喜你，你背靠npm这个全球最大的资源库，在这里你可以尽情享（bai）用（piao）那些全球开发者无私提供的资源。如果刚好你是一个用egg开发的开发者，那么你更幸运了，egg的插件机制让你能够只配置下config就能够玩转很多别人封装好的很多插件，如果找不到egg的插件也可以去找koa的包然后封装一下当中间件使用也是挺好的，egg的官方文档也给出了教程，不过在中间件封装然后日常使用的话我觉得就差点意思，egg的插件机制也没有充分利用起来，egg的插件相比于express或者koa的中间件有挺多的好处：
- 这点是官方文档给出来的，也是最重要的一点，就是“中间件加载其实是有先后顺序的，但是中间件自身却无法管理这种顺序，只能交给使用者。这样其实非常不友好，一旦顺序不对，结果可能有天壤之别。”
- 第二点也是官方给出的：中间件的定位是拦截用户请求，并在它前后做一些事情，例如：鉴权、安全检查、访问日志等等。但实际情况是，有些功能是和请求无关的，例如：定时任务、消息订阅、后台逻辑等等
- 前面的三点都是官方给出的：有些功能包含非常复杂的初始化逻辑，需要在应用启动的时候完成。这显然也不适合放到中间件中去实现。
- 第四点是我个人的观点：很多功能如果在中间件实现的话是不可控的，任何人都可以去更改，而且如果是做成插件的话也可以在项目中便于管理和分工，专门负责业务开发的人员可以专注于业务开发，不用去管插件的事，他们只需要提出自己的需求和使用插件反馈即行。
# 开发的需求
这次的需求就是我要用到一个第三方的SDK来满足开发，而且这个SDK因为需要调用SDK隶属方的请求地址，而且这个请求地址是分测试和正式的，而且如果在中间件上实现的话我觉得整个项目就不够精简了，感觉很突兀。
# 开发全过程
我先给出我写的插件的地址，首先我们还是按照官方给出的插件开发教程：
$ mkdir egg-plugin && cd egg-plugin
$ npm init egg --type=plugin
$ npm i
然后我们在根目录创建app.js文件，然后就是最关键的一部分：我们把app的config的插件配置值传进去：
'use strict';
const plugin = require('./lib/index.js');
module.exports = app => {
app.pluginName = new PddClient(app.config.pluginName);
};
一般的插件，首先都是要拿到自己在egg的config配置的值，而且封装的函数一般是写在lib文件夹下，然后return一个函数来挂载在app的pluginName（你自己定义的插件名）使用。
# 测试和发布
我们写完自己的功能之后可以在test文件夹下的controller那里写一下控制器模仿日常开发测试下插件的功能和稳定性等等，然后我们在npm网上发布自己的插件，当然首先你要拥有npm的账号以及写好你这个插件的README.md，我的README.md考虑到只能是国人来使用，所以就只写了中文版。然后我们来发布，首先在项目的根目录下登录npm的账号：
npm login
输入正确账号和密码之后就可以发布了，当然，发布npm包有很多可以装逼的地方，可以参考这篇文章。这边我们就先不装逼了，直接发布，不过在发布前先看下自己的npm包的源，
npm config get registry
如果输出的是“https://registry.npm.taobao.org/”，那么你就要更换成npm的官方源才行，不然发布是会报错的，这是一个大坑，第一次发布npm的小白肯定会中招：
# 切换为npm官方镜像源
npm config set registry https://registry.npm.taobao.org/
然后我们就能发布了：
npm publish
最后你就能在npm上看到属于你的npm包在上面了。
