开源 Web 前端工作流客户端 LegoFlow 2.0

[353943780]

由 Electron 做基础框架，内置 Webpack 4、Gulp 4、Babel 7 等比较前沿的构建工具模块。

至于为什么要把前端工作流封装成客户端的形式，主要是因为达到下载解压，开箱即用的方便性啊，不用配置什么各种麻烦复杂的系统环境。

不过对于动手能力强的开发者，CLI 还是挺爽的，所以同时也有提供 CLI 作为扩展工具。

关于 2.0 更加详细介绍的可以从 这里 了解到。

相关链接：官网 && Github

[onvno]

下载安装了客户端，随便说说吧。
客户端功能比较薄弱，扩展自定义是个大问题。
1. 是否暴露出配置更好，方便自定义配置
2. 项目目录结构如何支持比较大的项目？

[353943780]

@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)

[onvno]

@353943780 感谢这么用心的回复
第一方面我还是保留意见哈，不过对大型项目的目录结构处理，确实能简化开发和独立性，以后项目中可以实践下。
第二方面给到的官网地址公司内网打不开，回去我再学习下。