从迁移TypeScript说起 笔者所说的这个项目，是一个运行了接近五年的老项目，代码横跨es3到es6。而且代码风格由于项目的人员流动也各异。由于项目人数越来越多，以前留下的技术债造成的危害也越来越大。而重构，在这样一个臃肿且混乱的项目中显得举步维艰。由于JS的动态性，有的时候你甚至不知道这个方法是某个类下的实例方法还是JavaScript原生或是JQuery所提供的方法。 这个时候，TypeScript由于其提供的强类型能很好的规范代码，方便开发人员进行日常开发和重构，开始进入了我们的视野。 但是马上我们面对上了另一个难题，那就是，我们只想享受TypeScript强类型带来的类型推导的优势，并不想花大功夫去把整个代码库全部重构成TypeScript。 不过好在，TypeScript从2.3版本后就开始支持使用JsDoc的语法，以comment的形式给JavaScript文件提供强类型的支持。Type Checking JavaScript Files · TypeScript 如何开始使用Type Checking 首先你需要在你需要检查的JavaScript的文件头部显式的加上如下comment 1 // @ts-check 对变量进行类型检查 如果你需要声名一个变量的类型，你可以这样 1 2 3 4 5 /** @type {number} */ let x; x = 0; // OK x = false; // Error: boolean is not assignable to number 当你尝试给x赋一个bool值时，编辑器会提示你类型冲突。 对函数进行类型检查 当然某些时候我们最需要的其实是对于函数签名和返回值的强类型声名，以便我们在其他地方使用的时候不会传入错误的参数或者使用类型错误的函数返回值。TypeScript提供了三种语法来声名函数的类型. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 // jsdoc standard syntax // 声明一个函数 /** * @param {string} foo * @param {string} bar * @returns {string} */ function test(foo, bar) { return `${foo} and ${bar}` } // closure syntax // 声明一个函数表达式 /** * @type {function(string, string): string} */ let test; // test 必须符合定义的函数签名 test = (foo, bar, foobar) => '123' // 报错 函数不符合定义的签名 test = (foo, bar) => 1 // 报错 函数返回值不符合 // typescript like syntax // 声明一个函数表达式 /** * @type {(foo:string, bar:string) => string} */ let test; // test 必须符合定义的函数签名 在日常使用中，如果你想声明一个函数，对于函数做类型检查，你需要使用 @params @returns这种declaration 语法。 如果你想确定一个函数表达式的签名，你需要使用 @type的语法。 ...

背景 管理过在一个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的根目录。 ...

什么是 Jest Jest 是 Facebook 推出的一款开源的前端测试框架，或者我更愿意称其为包含了断言库 / 测试框架 / Mock 框架 / CLI 的开箱即用的前端测试套件。 Jest 和其他测试框架的区别 如果将常用的前端单元测试所需要的工具做横向分隔的话，其实可以分为这么几个大类。 测试框架 运行环境 Mock 框架 断言库 覆盖率工具 Jasmine karma sinon.js chai Istanbul mocha should.js 我们常说的前端测试框架比如 Jasmine 或者 Mocha 其实某种程度上并不能独立的运行起来并且集成在我们日常的工作流之中。比如最常见的 Jasmine，Jasmine 基本上很难去脱离 Karma 去使用，并且 Jasmine 自带的断言和 Mock 有的时候也无法完全满足我们的需求，可能还需要搭配 Sinon.js 或者 chai，最后配合 Istanbul 进行覆盖率分析。在实际的工作中，当你想基于 Jasmine 去构建项目的测试框架时，实际上你会发现，你的绝大多数时间都花在了搭建这些工作链上。 磨刀不误砍柴工，但是磨刀的时间太久也会消耗技术人员的耐心和热情，让一件事情变得难以实施。 而 Jest 主打的就是其开箱即用的特性，只需要很少的配置就可以很方便的接入现有项目之中。如果你恰巧使用了creat-react-app 这个脚手架的话，那么恭喜你，脚手架已经自带了 Jest 集成。 ...