[讨论] 优化插件系统

[loveky]

现有插件系统对用户不足够友好，遇到需要手动编写的情况，用户基本无法独立完成。

另外，插件这个名字本身也比较容易造成困扰。

[beanlee]

支持 yaml 或者 toml 类似配置文件去扩展？但是使用者又需要了解我们关于配置的有哪些选项，这个问题确实需要好好讨论，但其实最初设计的插件系统，包括暴露的API，已经蛮好用的了。

[beanlee]

插件开发的成本对于使用者来说，确实不太友好。修改 webpack 配置的过程需要用户学习 webpackChain 的 API 难免有点门槛。

可以暴露一个自定义webpack配置，支持用户直接写部分的 webpack 配置，然后我们在手动 merge 进来，如何？ @loveky

命令行的插件目前还没想到什么解决方案，而且命令行扩展需求一个也没接到……

[loveky]

可以暴露一个自定义webpack配置，支持用户直接写部分的 webpack 配置

倒是可以，问题是需要暴露哪些配置项呢？

另外，如果现在只有个别人需要修改配置，感觉也没有必要这么大改，ROI 不足

[beanlee]

可以暴露一个自定义webpack配置，支持用户直接写部分的 webpack 配置

倒是可以，问题是需要暴露哪些配置项呢？

另外，如果现在只有个别人需要修改配置，感觉也没有必要这么大改，ROI 不足

恩，我初步想，可以作一个插件，根据用户自己配置好的一个 webpack 的 js，直接读过来，merge 进来，大杀器一般的存在……

还有我们提供一个类似，create-react-app 里面的 eject 方法，把 webpack 全导出出来（工作量不小）

[loveky]

恩，我初步想，可以作一个插件，根据用户自己配置好的一个 webpack 的 js，直接读过来，merge 进来，大杀器一般的存在……

够用就好，如果小火箭以后不会持续推广和重度使用，那么可以使用一些简单粗暴的方式。

[beanlee]

恩，我初步想，可以作一个插件，根据用户自己配置好的一个 webpack 的 js，直接读过来，merge 进来，大杀器一般的存在……

够用就好，如果小火箭以后不会持续推广和重度使用，那么可以使用一些简单粗暴的方式。

是的，就是把责任都扔给使用者了。用户把自己用的 webpack 全写了，还用小火箭干嘛……