配置一个简单而实用的 JavaScript 开发环境
在一个框架、库和工具无处不在的时代，可能很多人都会面临选择困难症。
根据我的经验，写一个模块或 CLI 工具前你所要做的第一件事就是设置一个开发环境。对这个步骤有人喜欢有人愁。但不管怎样，它可能总是花掉你很多时间，你得不停地调整你配置的方方面面。
当然，你可能使用 webpack、eslint、jasmine 甚至是 TypeScript（而最终可能只换来“很棒”的编译错误信息）。事实上，大部分情况下，作为开发者，我们可以使用一些几乎不用配置的工具。通常来说，这些“开箱即用”的工具是完全可以接受的，并将帮助我们直接解决问题，同时还能提供几乎实时的反馈闭环。
当我们谈论最小化配置，我们最关注的是测试、代码规范检查、监控文件内容改变以及确保你在提交代码前没搞砸前面这些点。
下面是一个帮助你用五分钟或者更少的时间（取决于 NPM 的心情^^）一步步从无到有建立开发环境的步骤：
初始化 Node.js 项目和 Git 仓库
# 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"安装工具
在这里，我们将使用四个简单的模块，每个模块完成一件事。Ava 负责测试，Standard 负责代码规范检查，Chokidar-cli 负责文件监控，最后 Precommit-hook 负责自动运行 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 提交时，这些脚本也会被自动运行。除非你的测试和代码检查都通过，否则你无法提交代码。
两件值得注意的事：
- 你无须安装
standard或ava到你的系统全局域下，因为它们可以从node上下文里执行。 - 因为我们使用
&&代替;，在dev脚本里，单元测试在代码检查未通过前不会被触发。这让反馈闭环更快（即避免无谓的测试消耗时间）。
用这个配置工作
因为环境假定你使用 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好，现在测试通过了！就是这么简单。让我们创建另一个模块，它接受一个数值参数，让它的值加倍，然后对这个模块进行单元测试，看看是否它与我们的“生命的意义”模块能够很好地集成到一起（注意，到这里已经是集成测试，而不是单元测试！）。
// 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())它没问题！只需要几分钟时间，我们就可以让一切就绪。
我们作为开发者，经常被闪闪发光的新工具迷住。我们似乎忘记了那些工具本来应该让我们工作得更轻松、更快速和不容易出错。通常情况，最简单的解决方案就足够了。与其花费大量的时间在配置环境上，不如将时间花在编写软件本身上。而遵循上面的步骤将让你可以达到这一目的。
一但你的项目开始增长，你可能会发现自己需要引入一些更复杂的东西。然而，在大部分情况下，这一问题不会出现。上面那些工具会在很长很长一段时间内符合你的需求。