2
当前插件是渐进式开发的机制，从项目再独立出去，比较适合未曾发布过的插件，如果是一个已经在广泛被使用的插件上增加一些新特性，想使用NPM预发布的机制，让众多微服务中的一个或几个应用尝鲜用上预发布的版本，需要经历三个仓库的修改并发包：框架预发布 -> 插件预发布 -> 包含的中间件预发布，整个流程非常繁琐，有更好的解决办法吗？
Q
[eggjs/egg]插件包预发布链式依赖问题
A
回答
9
插件发布一个 next 的 dist-tag 版本。 然后在应用里面引入这个 deps，在应用的 plugin.js 里面配置一次这个插件的 plugin.js
4
@atian25 这是个办法，但是还是有两层。有没有只需要发布一个中间件 dist-tag 包的办法？
2
你们还维护了一个单独的中间件？ 我们现在最小的可复用功能都以插件为主了。
2
这是 npm 层面的问题了，egg 最小的加载颗粒度是插件，如果你是中间件的话，那直接应用的 app/middleware 里面引入这个中间件吧。
可以试一下，应用里面写一个同名的 middleware 看看是否会覆盖，我不确定，不太记得了，可能会报错。
或者你在你的插件里面，挂载中间件的地方，判断下环境变量啥的来选择不同名字的 middleware 吧，这属于代码操作层面的了。
1
koa 中间件，是由开源项目改造过的。 插件用来管理中间件配置，正式和测试环境使用不同的配置； 中间件作为一个功能；
你们现在是提倡把 koa middleware 直接写到 egg plugin 代码中吗？
我试下你说的方法。
2
middleware 一般用于表述请求过程中的处理，而一般我们都是为了增加一些其他的功能，这些不是中间件的。
我们是基于 egg 开发的，所以很多时候，除了一些开源的 middleware 外，其他的一般我们都直接写成插件了。
刚才提的方式是：
在应用层直接引入这个 middleware 的 next 版本，然后在应用的 app/middleware 下搞一个同名的，看看能否覆盖插件自带的。 如果不行，那就在应用层搞一个 xx_next 的中间件，然后在插件里面判断某个变量，在挂载中间件的时候，来选择不同的。
8
验证了，方式1可以做到，就用这种方式好了。感谢！！！@atian25
0
有空写下你们这套模式分享出来吧