在一个框架、库和工具无处不在的时代,可能很多人都会面临选择困难症。
根据我的经验,写一个模块或 CLI 工具前你所要做的第一件事就是设置一个开发环境。对这个步骤有人喜欢有人讨厌。但不管怎样,它可能总是花掉你很多时间,你得不停地调整你配置的方方面面。
当然,你可能使用 webpack、eslint、jasmine 甚至是 TypeScript(而最终可能只换来 "很棒" 的编译错误信息)。事实上,大部分情况下,作为开发者,我们可以使用一些几乎不用配置的工具。通常来说,这些 "开箱即用" 的工具完全可以接受的,并将帮助我们直接解决问题,同时还能提供几乎实时的闭环反馈。
当我们谈论最小化配置,我们最关注的是测试、代码规范检查、监控文件内容改变以及确保你在提交代码前没搞砸前面这些点。
下面是一个帮助你用五分钟或者更少的时间(取决于 NPM 的心情 ^^)一步步从无到有建立开发环境的步骤:
- # Create a directory and cd into it (#protip – $_ holds argument of your last command)
- $ mkdir awesome-module && cd $_
- # Initialize Node.js project with default settings
- $ npm init --yes
- # Create initial folders and files
- $ mkdir lib test
- $ touch index.js lib/meaningOfLife.js test/index.test.js test/meaningOfLife.test.js
- # Initialize GIT repository and create initial commit
- $ git init
- $ git add -A; git commit -am "Awesome Module, day one"
在这里,我们将使用四个简单的模块,每个模块完成一件事。 负责测试, 负责代码规范检查, 负责文件监控,最后 负责自动运行 npm 脚本。
为什么选择这几个工具?因为它们不需要任何配置即符合我们使用者的思维习惯。这样少一件事情(指修改配置)需要思考和担心。
- $ npm i --save-dev ava standard chokidar-cli precommit-hook
记得创建 .gitignore 文件并添加 node_modules 目录到文件中!我们不需要将依赖的库提交到我们的代码仓库里。
打开 package.json 并添加这些脚本到你的文件:
- "scripts": {
- "test": "ava",
- "lint": "standard",
- "dev": "chokidar " * *
- /*.js" -c "standard && ava""
- },
- "pre-commit": ["test", "lint"],*/
就这样,一切都搞定了!一旦你运行 npm run dev ,所有的 JS 都会通过 Standard.js 进行规范检查,并通过 Ava 进行单元测试。不用额外做别的什么了,你现在就可以开始你的工作。
同样,提交 Git 提交时,这些脚本也会被自动运行。除非你的测试和代码检查都通过,否则你无法提交代码。
两件值得注意的事:
因为环境假定你使用 TDD(测试驱动开发)方式工作(你可能应该这么做!),一但你运行你的 dev 脚本,你可以创建测试并且将它们添加到测试用例集中,不需要重启监控程序或者重新构建。
让我们创建第一个测试文件:
- // test/meaningOfLife.test.js
- const test = require("ava")
- const meaningOfLife = require("../lib/meaningOfLife")
- test("Real meaning of life", (t) => {
- t.is(meaningOfLife(), 42)
- })
一但你保存文件,你会立即发现你的一个测试用例未通过,让我们来修复它:
- // lib/meaningOfLife.js
- module.exports = () => 42
好,现在测试通过了!就是这么简单。让我们创建另一个模块,它接受一个数值参数,让它的值加倍,然后对这个模块进行单元测试,看看是否它与我们的 "生命的意义" 模块能够很好地集成到一起(注意,到这里已经是集成测试,而不是单元测试!)。
And we are back to green! It's as simple as that. Let's create another module that'll multiply a numeric parameter, unit test this module and see whether it'll work nicely with our "meaning of life" (note that it's already an integration test, not unit!).
- // lib/multiply.js
- module.exports = (number) => {
- if (typeof number !== "number") throw new TypeError("Only numbers can be multiplied!")
- return number * 2
- }
- // test/multiply.test.js
- const test = require("ava")
- const multiply = require("../lib/multiply")
- test("Can multiply numbers", (t) => {
- t.is(multiply(10), 20)
- })
- test("Throws when you try to multiply non-number value", (t) => {
- t.throws(() => multiply("ohai!"), "Only numbers can be multiplied!")
- })
现在,让我们把两者放在一次测试:
- // test/index.test.js
- const test = require("ava")
- const awesomeModule = require("../index")
- test("Works nicely together", (t) => {
- t.is(awesomeModule(), 84)
- })
- // index.js
- const meaningOfLife = require("./lib/meaningOfLife")
- const multiply = require("./lib/multiply")
- module.exports = () => multiply(meaningOfLife())
它没问题!只需要几分钟时间,我们就可以让一切就绪。
我们作为开发者,经常被闪闪发光的新工具迷住。我们似乎忘记了那些工具本来应该让我们工作得更轻松、更快速和不容易出错。通常情况,最简单的解决方案就足够了。与其花费大量的时间在配置环境上,不如将时间花在编写软件本身上。而遵循上面的步骤将让你可以达到这一目的。
一但你的项目开始增长,你可能会发现自己需要引入一些更复杂的东西。然而,在大部分情况下,这一问题不会出现。上面那些工具会在很长很长一段时间内符合你的需求。
来源: