工程师的执拗

什么是Github Actions Github Actions 是 Github 推出的一项服务，旨在以自定义工作流的方式来简化团队开发协作中的各种需求。比如： 基于 Code Commit 的代码构建/测试/打包，也就是常说的持续集成。 应用的自动发布和部署，和上一步连起来就是所谓的持续部署。 自动管理 PR（如自动 assign viewer） 自动管理 issue（如自动给 issue 分类，自动关闭长期不更新的 issue ） Github Actions的优点 1. 灵活性 对比主要竞品 Jenkin/GoCD 以及 Circle CI/ Travis CI， 相较于 Jenkins/GoCD 只能够自建服务，CirCle CI(2.0以前) / Travis CI 只能依靠官方提供的服务，Github Actions 可以使用 Github 官方的 Runner，同时 Github Actions 也支持使用用户自建的（比如搭载某内网环境的instance）Runner。Github Actions 还自带 Linux/macOS/Windows 三种类型的 Runner，能够满足不同用户群体在不同场景的需要。 2. 复用性 对于开发者而言，编写重复的代码永远都是一种灾难。而在 Github Actions 的准则中，每一条 Action 都是一个最小的可复用单元，只需要一次编写，便可以在之后随时随地的使用。更棒的是，Action 可以通过组合的方式来使用，完成更为复杂的功能。 3. 可维护性 每一条 Action 其实就是一个 JavaScript module/Docker container，由于Action 本身就是代码，所以 Action 本身是可以很好的被版本管理的。同时由于支持使用 JavaScript 编写 Action，只要你想，你可以使用大量的测试来保证你的 Action 的质量。 ...

什么是yeoman generator 真正开始写一个yeoman脚手架之前，我们需要先搞清楚 generator 这个名词。 generator是yeoman提供的对于脚手架的封装，每一个generator是一个单独的npm package。不同的generator之间可以通过组合生成新的generator(e.g. generator-generator是对于generator-node的组合 ) 如果你想使用一个已经发布的generator，你只需要 1 2 3 yarn global add yo generator-[generator-name] # e.g generator-node yo [generator-name] # e.g yo node 如何编写一个yeoman generator 上面也提到过generator其实是yeoman提供的一个对于脚手架抽象的封装，所以在yeoman对于generator的项目结构也做出了一些开发者必须要满足的要求。 在项目的package.json中 项目必须依赖于 yeoman-generator, 项目 keywords 必须有 yemoan-generator package名应该以generator-[generator-name]的格式进行命名 项目结构 yeoman generator支持两种不同的项目组织模式 模式1 ├───package.json └───generators/ ├───app/ │ └───index.js └───router/ └───index.js 模式2 ├───package.json ├───app/ │ └───index.js └───router/ └───index.js 需要注意的是， 第二种模式下必须要在pacakge.json里面显式的做出声明 1 2 3 4 5 6 { "files": [ "app", "router" ] } 一个最简单的generator 以下是一个最简单的Generator ...

背景 管理过在一个javascript repo下面有多个子project的同学可能都遇到过依赖管理困难的问题。对于一些公用的包（比如node-sass），我们想尽可能保证版本的一致，享受yarn的hoist特性，同时也不想下载多次。但是对于一些特殊的包，我们又想保持各个repo的独立性。 在Yarn 1.0版本以前，以上念想其实是很去实现的，我们不得不花费大量的人力去维护我们各个子project的依赖包关系。但是Yarn在1.0版本引入了workspace 这个特性之后，这些问题就不再存在了。 什么是workspace yarn官方对于workspace的定义是It allows you to setup multiple packages in such a way that you only need to run yarn install once to install all of them in a single pass. 。简而言之，workspace能帮助你更好的管理有多个子project的repo。你既可以在每个子project下使用独立的package.json管理你的依赖，又可以享受一条yarn命令安装或者升级所有依赖的都便利性。 workspace能帮你做什么 简而言之，workspace能帮你做这么两件事情 简化你的工作流 当你有多个子project的时候，你可能做的最多的事情就是分别进入每个文件夹，然后执行yarn install 或者 yarn upgrade foo。 但是引入workspace之后你需要的只是一条在根目录运行yarn install或者yarn upgrade foo命令，你的所有的依赖都会被安装或者更新。 降低包安装和包升级的成本 这里讲的成本主要指的是时间成本和管理的精力成本。 时间成本 在使用workspace之前，你想要安装整个repo的依赖时，你需要独立安装每个子project的依赖。这就意味着，如果你的repo下面同时以来于node-sass，你需要重复下载三次node-sass的安装包。当你的子project或者包依赖并不是特别多的时候，这些时间成本似乎影响并不是那么大。但是随着你的repo越来越大，依赖越来越复杂，消耗的时间也会变得越来越恐怖。 在引入workspace之后，yarn会帮助你分析各个子project里面的依赖关系，保证所有子project里面共同的依赖只会被下载和安装一次，大大缩减安装的时间。 精力成本 设想我们引用了一个有严重安全漏洞的包foo，我们想要将整个repo中的这个包都升级到最新版本来修复这个严重的安全漏洞。在没有使用workspace之前，你需要仔细且耐心的遍历每个子project的package.json文件，然后手动执行升级操作。 在引入workspace之后，你大可以在repo的根目录简单运行一条yarn upgrade foo命令，你的所有子project中依赖的foo包都会自动升级到package.json里面指定的版本。 当然，如果你想单独的升级某个子project的包，可以简单的使用yarn workspace <workspace-name> upgrade … 来做到。 怎么使用workspace yarn workspace并不需要安装什么其他的包，只需要简单的更改package.json便可以工作。 首先我们需要确定workspace root，一般来说workspace root都会是repo的根目录。 ...