LegoFlow 2.0 开源更轻、更强的前端工作流客户端

2,101 阅读4分钟
原文链接: zhuanlan.zhihu.com

背景

对于前端开发者来说,脚手架工作流是工作每天接触的东西。那么意味着稳定、高效、靠谱的工作流对于工作效率是多么的至关重要。

这几年部门组内的工作流迁移,随着业界也变化了不少,详细浏览这篇 文章

LegoFlow 是对于现有工作流探索中,最接近我们理想形态的产物。

在上年六月份,对外公布了 1.0 版本,虽然没有公开源码,但同样收获了不少的反馈,十分感谢 各位的支持以及肯定。

2.0 Github

在这之后,我们一直在准备 2.0 版本的事情,实际上最大的驱动力,主要来源于两个大模块的更新, Webpack & Babel 的新版本发布。

所以 2.0 内置集成了 Webpack 4Gulp 4Babel 7 等相对前沿的构建工具模块。

而在今天,好不容易终于迎来了 2.0 版本,与 1.0 版本有很大区别:

1. 完整项目开源

我们重写了整个项目的结构。由于 Electron 1.8.4 版本集成了 Node.js 8.x 版本的环境,一些复杂的回调嵌套,使用 async/await 去进行重构,让大量的代码阅读性更好。

另外,随着 Electron 使用量的增加,更多模块 以及 Loader 尽量暴露依赖,避免内置 require 固定的路径,得益于此,2.0 相比起 1.0 减少了 hack 重写依赖模块、改写依赖路径的行为,增加方便使用者对源码上的理解。

2. Webpack 4.5 & Babel 7

升级了内置的 WebPack 4.5 版本,支持大量 新特性

另外升级使用 Babel 7,虽然它还处于 Beta 阶段,但是一些新特性真的令人惊喜,例如:

optional-chaining
const obj = { x: 1 };

console.log( obj.x ); // 1
console.log( obj.y ); // undefined
console.log( obj.x?.y ); // undefined
console.log( obj.y?.x ); // undefined

使用场景,在客户端内嵌页的开发中,经常会使用一些客户端注入的 SDK 方法,例如

window.SDK.alert( );

但在调试中,脱离了客户端的环境,本应被注入的 SDK 对象找不到了,经常会发生报错 `SDK undefined` 中断了代码的执行。

这无疑是很糟糕的体验,如果对于 optional-chaining 便可以完美地避免这样的情况,只需把逻辑代码换为

window.SDK?.alert( );
pipeline-operator
function add ( x ) { return x + x; }
function double ( x ) { return x * 2; }

let x = 2
 |> add
 |> double

类似一些其他语言 Elm、OCaml 等,还能支持 await,让 "管道" 操作更加语义化。

3. 提供 CLI 工具

捕捉客户端的错误问题,一直是件头疼的问题,因为它约相当于一个黑盒子。

一旦发生意料之外的错误,客户端就难以表达完整的错误信息,提供给使用者排除问题,而且对于动力能力较强的使用者来说,CLI 更加适合使用以及扩展。

这样那样的种种原因,我们提供了 CLI 工具

当发现 客户端 不能满足需求时候,请尝试使用它,你会发现不一样的好用。

4. 更好的扩展性

重构之初,考虑到了更加好的扩展,我们把核心的 "工作流引擎" 单独抽出来作为公共模块,提供给 客户端 以及 CLI 使用。

换句话来说,无论是客户端还是 CLI 都是上层一个的 "壳",只是把参数获取整理好后,传递给核心工作流模块工作。

也就意味着,只要引用了这个 "引擎",启动的钥匙就掌握在你的手上,如果你不喜欢提供的 客户端 或者 CLI,大可以动手实现自己的理想的外形,然后只需简单引入启动这个核心 "引擎" 即可。

另外,客户端 或者 CLI 创建的项目,都能很好地运行在对方上,也就是 2.0 版本创建的项目,无论是哪个工具创建,都能运行在其他工具上。

这就是为什么把 "Project" 模块分离出来的原因。

同样原因,我们把 "Config" 模块也分离了,客户端 以及 CLI 可以共享的同一份通用的全局设置,无需重复配置。

解耦出这些模块,最根本的原因是为了让 LegoFlow 项目,实现在多工具多端的通用运行。

所以如果你有更棒的想法,只要包含并使用同样上述的三个模块构建而成的工具,同样得到与其他工具通用的效果。

这不但统一规范的通用形态的项目,实现了组内项目的标准化,而且同时给予开发者更大自由发挥的空间,创作出自己的理想开发工具。

最后

在探索着工作流这个事情上,花了挺大的力气让 理想现实 贴近些。

如果你有更棒的想法或者问题,欢迎提交 PRs 或 issues,谢谢。