@
onvno 首先关于 “功能薄弱”，不太赞同，大可了解一下现有其他工作流功能进行对比，以及为什么需要采用 Babel 7 有什么好处等等，而且更有些是文档没写，例如 TS 的支持等等。
而对于扩展自定义的问题，可以分为两个方面表述，第一个是自定义工作流任务，第二个是工作流后处理。
第一个方面的确跟内部 engine 挂钩，我们尽量是希望开发者做最少的事情，让客户端做更多的事情，但是如果什么都让开发者自定义，无疑这样违背我们的初衷，而现有功能足足支撑了整个部门运行了一两年，而且推到其他的部门使用中。
另外为什么不暴露配置？现在内置的 Webpack 4，但有些配置项跟 v2 已经是变得面目全非，如果单纯地暴露配置，兼容客户端过往版本到后期必然是个问题，但是提供自己的配置属性的话，客户端的内部可以做兼容处理，而不是版本更新了又需要开发者去了解版本配置有哪里不一样，所以为什么工具升级跑久项目各种问题多痛苦的根源在此。或者有什么更好的想法欢迎提 PRs。
第二方面是工作流后处理，这个是对工作流构建完成后要做什么事情，例如上传到 FTP，打包 zip 等等一些的功能，其实这个可以通过自定义 [shell](
https://legoflow.com/wiki/#shell-%E8%84%9A%E6%9C%AC%E6%9C%BA%E5%88%B6) 实现。
另外大型项目的目录结构，我们的做法是，一些模块抽离到外部，再由总的入口 import。例如，有个电商项目，先抽离开各种模块，支付模块，购买流程模块等等，发布到内部私有的 npm 仓库，再通过 app 项目下的 js/main.js 引入相关路由懒加载的 npm 模块，所以总的入口有一个，但分配到路由下每个独立的 npm 模块负责，然后每个人负责不同的模块。这整个电商项目的架构共有几十余人参与。
另外一些详细的资料可以翻看 [这里](
https://zhuanlan.zhihu.com/p/36414272) 或 [这里](
https://zhuanlan.zhihu.com/p/27355765)