开源javascript库
by Sarah Dayan
通过莎拉·达扬
如何自动化您的开源JavaScript项目最重复的任务 (How to automate your open source JavaScript project’s most repetitive tasks)
When I started my career, my mentor told me:
当我开始职业生涯时，我的导师告诉我：
“A good developer is a lazy developer. Don’t waste time on repetitive tasks, instead spend it on building automated processes. The computer works for you, and it will always be faster than you.”
“好的开发人员就是懒惰的开发人员。 不要将时间浪费在重复的任务上，而要花时间在构建自动化流程上。 计算机为您工作，并且永远比您更快。”
This was back in 2010, and the toolset we had at our disposal was more scarce than it is today. Yet, this piece of advice has stuck with me ever since.
早在2010年，我们所拥有的工具集就比今天更加稀缺。 从那时起，这条建议就一直困扰着我。
From executable scripts to Yeoman configs, IFTTT setups and Automator workflows, not to mention the slew of apps I use to assist my every move on the computer. I see automation as a game and take a lot of satisfaction in it.
从可执行脚本到Yeoman配置，IFTTT设置和Automator工作流，更不用说我用来协助我在计算机上进行所有操作的大量应用程序。 我将自动化视为一种游戏，并且对此感到非常满意。
JavaScript has exploded since then, and has grown in complexity. We used to add an external JavaScript file to an HTML page and call it a day. But there’s much more to building a web project now than just coding. We also have more tools than we can use to unload repetitive tasks, so finding your way through it all can be overwhelming.
从那时起，JavaScript就爆炸了，并且变得越来越复杂。 我们曾经将外部JavaScript文件添加到HTML页面，并称之为一天。 但是，现在构建一个Web项目不仅仅需要编码。 我们还拥有更多的工具来卸载重复的任务，因此在所有过程中找到自己的方法可能会令人不知所措。
To sort this out, I decided to show you the detailed setup for a real-life project- my latest open source project, Dinero.js.
为了解决这个问题，我决定向您展示一个真实项目的详细设置-我最新的开源项目Dinero.js 。
Disclaimer: This isn’t a tutorial on how to make an open source library, but rather an overview of what I use, how, and why. For a thorough step-by-step guide, I recommend the egghead.io course How to Write an Open Source JavaScript Library by Kent C. Dodds.
免责声明：这不是有关如何制作开源库的教程，而是有关我使用的内容，方式和原因的概述。 要获得详尽的循序渐进指南，我建议阅读Kent C. Dodds的egghead.io课程“ 如何编写开源JavaScript库” 。
依赖管理 (Dependency management)
npm和纱线 (npm and Yarn)
Before the modern times, we used to download dependencies by hand and load them globally in pages. This made things easy but led to a number of problems like duplicate libraries, heavy repositories, difficult version management.
在近代之前，我们曾经手动下载依赖项并将其全局加载到页面中。 这使事情变得容易，但是导致了许多问题，例如重复库，繁重的存储库，困难的版本管理。
Fortunately, we now have a robust and trust-worthy front-end dependency manager: npm. If you come from PHP, you can see npm like Composer and Packagist put together. It provides the richest front-end repository out there, and a great command-line interface to handle dependencies.
幸运的是，我们现在有了一个健壮且值得信赖的前端依赖项管理器： npm 。 如果您来自PHP，则可以看到像Composer和Packagist一样的npm。 它提供了最丰富的前端存储库，以及一个强大的命令行界面来处理依赖关系。
Many people (including me) prefer using Yarn though: a faster CLI that integrates a powerful cache system, parallelize downloads and provides an offline mode. Now Yarn is only a layer on top of the npm repository: it browses npm packages, but allows you to use their tool instead.
但是，许多人(包括我在内)都喜欢使用Yarn ：更快的CLI，它集成了强大的缓存系统，并行下载并提供了脱机模式。 现在，Yarn 只是 npm存储库之上的一层：它浏览npm软件包，但是允许您使用其工具。
编码风格和约定 (Coding style and conventions)
编辑器配置 (EditorConfig)
Imagine you’re working on several projects, all of which have different conventions. On this library you chose two-space indentation, but this other open source project you contribute to prefers four-space long tabs. Are you going to manually reconfigure your editor every time you switch?
假设您正在从事多个项目，所有项目都有不同的约定。 在该库中，您选择了两个空格的缩进，但是您贡献给另一个开源项目则更喜欢使用四个空格的长制表符。 您是否要在每次切换时手动重新配置编辑器？
EditorConfig is a configuration file that lives in your project and defines editor settings. Every time you work on a project that has an .editorconfig file, your editor will conform to its rules.
EditorConfig是一个配置文件，位于您的项目中并定义编辑器设置。 每次处理具有.editorconfig文件的项目时，编辑器都将遵守其规则。
Most editors can parse .editorconfig files, but if it’s not the case for yours you can still download a plugin.
大多数编辑器都可以解析.editorconfig文件，但是如果不是这种情况，您仍然可以下载插件 。
更漂亮 (Prettier)
One of the tools I am most grateful for is Prettier. I dig it so much that I have it as an npm script in my project and as a code editor plugin. That’s how deep my love is.
我最感谢的工具之一是Prettier 。 我对它的挖掘如此之多，以至于我将其作为项目中的npm脚本以及作为代码编辑器插件使用。 那就是我的爱有多深。
Prettier solves the problem of arguing over coding style and wasting time in code review. No more heated discussions around simple vs. double quotes. No more rejected Pull Requests because you forgot a space before an if parenthesis.
更漂亮的解决了在编码审查中争论编码风格和浪费时间的问题。 不再围绕单引号和双引号进行激烈的讨论。 不再有拒绝的“拉取请求”，因为您在if括号之前忘记了空格。
And above all things, no more wasted time formatting code by hand. Prettier is opinionated, so you’ll get limited room for customizing the default rules. And that’s for the best: that’s not what you should spend your precious time on.
最重要的是，不再需要浪费时间手动设置格式代码。 更加漂亮，因此自定义默认规则的空间有限。 那是最好的 ：那不是您应该花费的宝贵时间。
ESLint (ESLint)
Like with grammar and spelling, your code isn’t immune to typos. Also, it’s not unlikely to accidentally add code that may introduce bugs, like globals or unwanted type coercion.
像语法和拼写一样，您的代码也无法避免拼写错误。 此外，不太可能偶然添加可能引入错误的代码，例如全局变量或不需要的类型强制。
This is what ESLint takes care of. It will not rewrite your file like Prettier does, but you’ll get warnings in the terminal.
这是ESLint照顾的。 它不会像Prettier那样重写您的文件，但是您会在终端中收到警告。
There is some common territory between ESLint and Prettier, which is why I recommend that:
有一些ESLint更漂亮之间的共同领地 ，这就是为什么我建议：
- You run Prettier first, then ESLint. 您先运行Prettier，然后运行ESLint。
You use a tool that ensures they don’t conflict with one another, like eslint-config-prettier.
您使用一种工具来确保它们不会相互冲突，例如eslint-config-prettier 。
Commitizen和cz-常规更改日志 (Commitizen and cz-conventional-changelog)
You’re probably starting to see a pattern here: yes, I’m big into conventions. I’d rather trust a convention and focus on my job than fall into the rabbit hole of bikeshedding, and commit messages fall under that category. Now the idea behind conventional commit messages isn’t only to make pretty commits, it’s about automating a large part of your CI workflow.
您可能开始在这里看到一种模式：是的， 我热衷于约定 。 我宁愿相信一个约定并专注于我的工作，而不愿陷入Bikeshedding的困境 ，而提交消息属于该类别。 现在，传统提交消息背后的想法不仅是进行漂亮的提交，还在于使CI工作流程的大部分自动化。
When you maintain software, there are some tedious tasks that need to be taken care of. Among them are keeping a changelog up to date and versioning the project.
维护软件时，需要完成一些繁琐的任务。 其中包括保持最新的变更日志和项目版本化 。
Maintaining a changelog by hand is a pain. You have to check every commit since the latest release, filter out what doesn’t concern the user (changes to the build system, non-breaking refactors), find out what effective changes were made and write it down in a human-readable way.
手工维护变更日志是很痛苦的。 您必须检查自最新版本以来的所有提交，筛选出与用户无关的内容(对构建系统的更改，不间断的重构)，找出进行了哪些有效的更改并以易于理解的方式将其记录下来。
Same goes for the version.
版本也一样。
Depending on the changes, you need to resolve what the next version is. No matter how well you think you know semver, it can be tedious to increment the version by hand. Human error easily leads to incorrect versions, and this can be a big problem for users.
根据更改，您需要解决下一个版本。 无论您认为semver多么熟练 ，手动增加版本都是很乏味的。 人为错误很容易导致版本不正确，这对用户来说可能是个大问题。
This is what Commitizen and cz-conventional-changelog take off your plate. Instead of committing the usual way, you run a script that asks you questions. It will then commit for you with a properly formatted message that follows the Angular Git Commit Guidelines. Later on, when you deploy with semantic-release, those commit messages will be used to generate the changelog and resolve the new version number. Automatically. Nice, right?
这就是Commitizen和cz-conventional-changelog的 亮点 。 您不必执行通常的方法，而是运行一个脚本询问您问题。 然后，它将按照Angular Git提交准则为您提供格式正确的消息。 稍后，当您使用语义发布进行部署时，这些提交消息将用于生成变更日志并解析新的版本号。 自动。 好吧
皮棉阶段 (lint-staged)
If you’re working in a team, one of the best ways to ensure code quality is doing code reviews. It’s paramount that code going to production goes under at least a second pair of eyes.
如果您在团队中工作，确保代码质量的最佳方法之一就是进行代码审查 。 至关重要的是，将要投入生产的代码至少要经过第二双眼睛。
Now because they’re time-consuming, it’s important that code reviews observe a few rules. Among those, review time shouldn’t be used to spot linting errors.
现在，由于它们很耗时，因此代码审查必须遵守一些规则，这一点很重要。 其中， 不应将检查时间用于发现掉毛错误 。
All formatting and linting should happen before committing. It shouldn’t distract the reviewer from doing their job, and it shouldn’t break the build. This is why lint-staged is so useful: every time you commit, it will act as a pre-commit hook and run a script of your choosing.
所有格式化和掉毛都应在提交之前进行。 它不应分散审稿人的工作，也不应破坏构建。 这就是为什么lint-staged如此有用的原因：每次提交时，它将充当预提交的钩子并运行您选择的脚本。
In Dinero.js, here’s what my lint-staged configuration looks like:
在Dinero.js中，这是我的分阶段配置的外观：
{ "lint-staged": { "*.js": ["npm run lint!", "git add"] }}The npm run lint! command sequentially triggers two other scripts: npm run format (Prettier), then npm run lint (ESLint). Every time I try to commit a JavaScript file, Prettier will reformat it. Then, ESLint will perform a scan: if it passes, the commit will go through. Otherwise, ESLint will throw an error and the commit will be aborted.
npm run lint! 该命令依次触发其他两个脚本： npm run format (Prettier)，然后npm run lint (ESLint)。 每当我尝试提交JavaScript文件时，Prettier都会重新格式化它。 然后，ESLint将执行扫描：如果通过，则提交将通过。 否则，ESLint将引发错误，并且提交将被中止。
文献资料 (Documentation)
JSDoc (JSDoc)
Documentation should live as close as possible from the code it describes. This is a good way to keep it up to date and guarantee its exhaustiveness. A great implementation of this idea is doc blocking: using formatted comments to document code, which can then automatically generate a documentation website. In JavaScript, the most popular documentation generator is JSDoc.
文档应该与其描述的代码尽可能接近。 这是保持其最新状态并确保其详尽无遗的好方法。 这个想法的一个很好的实现是文档阻止 ：使用格式化的注释来编写文档代码，然后可以自动生成文档网站。 在JavaScript中，最受欢迎的文档生成器是JSDoc 。
With JSDoc, all you need to do is add a comment with specific tags and descriptions above every significative part of the code (a function, a module, etc.)
使用JSDoc，您要做的就是在代码的每个重要部分(函数，模块等)上方添加带有特定标记和描述的注释。
{ /** * Returns the currency. * * @example * // returns 'EUR' * Dinero({ currency: 'EUR' }).getCurrency() * * @return {String} */ getCurrency() { return currency }}This doc block has a description, one example and a typed return value.
此doc块具有描述，一个示例和类型化的返回值。
Once written, doc blocks can be turned into a documentation website with a single command. You can use any pre-existing JSDoc template to generate your website or create yours.
写入文档块后，只需一个命令即可将其转换为文档网站。 您可以使用任何现有的JSDoc模板来生成您的网站或创建您的网站。
为什么不选择ESDoc？ (Why not ESDoc?)
The younger kid on the block, ESDoc, takes a different approach than JSDoc. Among other things, ESDoc was designed to work well with ES6 classes, and concrete code in general. The downside is that it doesn’t support factory functions.
街区中的小孩子ESDoc与JSDoc采用不同的方法。 除其他事项外，ESDoc旨在与ES6类以及一般的具体代码配合使用。 缺点是它不支持工厂功能 。
Factory functions are dynamic object generators, a behavior that ESDoc doesn’t cover. If you try to document a factory with ESDoc, the generated documentation will come back empty.
工厂函数是动态对象生成器，ESDoc没有涵盖这种行为。 如果您尝试使用ESDoc对工厂进行记录，则生成的文档将恢复为空。
In my case, factories are the building blocks of Dinero.js, which explains my choice.
就我而言，工厂是Dinero.js的基础，这解释了我的选择。
If your project uses the ES6 class syntax, ESDoc will meet all your needs. Else, go with JSDoc: it supports all ES6 features, as well as “older” patterns like factory functions and the original syntax for constructors.
如果您的项目使用ES6类语法，则ESDoc将满足您的所有需求。 否则，请使用JSDoc：它支持所有ES6功能，以及“较旧的”模式，例如工厂函数和构造函数的原始语法。
阿尔戈利亚DocSearch (Algolia DocSearch)
You may have written your documentation with care and presented it in a pretty website, at the end of the day, what matters is for users to find what they need as quickly as possible. Nobody likes to break their flow for too long to go find something they need. It’s no surprise StackOverflow is so popular: people need answers to their questions, and they need it fast.
您可能会小心翼翼地编写文档，并在一天结束时将其展示在一个漂亮的网站中，对于用户而言，重要的是尽快找到他们所需的内容。 没有人喜欢中断他们的流程太长时间以至于找不到他们需要的东西。 不足为奇的是StackOverflow如此流行：人们需要他们的问题的答案，而且需要快速解决 。
Algolia is the best search service out there. Their (free) DocSearch solution lets you create an excellent documentation experience for your users. DocSearch is an on-demand service: once your docs are ready, send them a URL and you’ll get a code snippet to add to your website.
阿尔戈利亚是那里最好的搜索服务。 他们的(免费) DocSearch解决方案使您可以为用户创建出色的文档体验。 DocSearch是一项按需服务：准备好文档后，向其发送一个URL，您将获得一个代码段以添加到您的网站中。
测验 (Tests)
摩卡和柴 (Mocha and Chai)
Unit testing is crucial. If you can only do one thing for code quality, forget linting, forget formatting, forget code reviews and write unit tests.
单元测试至关重要。 如果您只能为代码质量做一件事，那就不要掉线，忘记格式化，忘记代码审查和编写单元测试 。
Unit testing forces you to build modular, single-responsibility code and ensures you don’t break things that used to work fine. It’s a crucial part of continuous integration. If you’re serious about what you’re building, you should 100% unit test it.
单元测试迫使您构建模块化，单一职责的代码，并确保您不会破坏正常运行的工作。 这是持续集成的关键部分。 如果您对构建的东西很认真，则应该对其进行100％的单元测试。
Now if you’re just starting out, unit testing may seem a bit scary. The good news is they don’t have to be: thanks to tools like Mocha and Chai, writing tests comes really close to being fun.
现在，如果您刚刚开始，单元测试可能会有点吓人。 好消息是它们不必一定是：借助Mocha和Chai之类的工具，编写测试真的很有趣 。
Here’s an excerpt from my unit tests for Dinero.js:
这是我对Dinero.js的单元测试的摘录：
import chai from 'chai'import Dinero from '../../src/dinero'const expect = chai.expectdescribe('Dinero', () => { describe('#getAmount()', () => { it('should return the right amount as a number', () => { expect(Dinero({ amount: 500 }).getAmount()).to.equal(500) }) it('should return the default amount as a number when no amount is specified', () => { expect(Dinero().getAmount()).to.equal(0) }) })})This JavaScript file, called a “spec”, uses the Mocha framework and the Chai assertion library. The public API is built to look like actual English sentences: even non-technical people can read the spec files and understand what’s going on. This makes it easy for new contributors, because the learning curve is almost non-existent.
该JavaScript文件称为“规范”，使用Mocha框架和Chai断言库。 公共API的构建看起来像实际的英语句子：甚至非技术人员也可以阅读规范文件并了解正在发生的事情。 这对于新的贡献者来说很容易，因为学习曲线几乎不存在。
Tests using Mocha and Chai are natively run with Node.js, which means it expects CommonJS modules for the spec and source files. But thanks to Babel, we don’t have to write CJS if we don’t want to: we can still use ES modules and transpile them on the fly as we run tests! This is how I’m able to include modules with import instead of require and still have fully working tests.
使用Mocha和Chai进行的测试在本机上是通过Node.js运行的，这意味着它期望规范和源文件使用CommonJS模块。 但是感谢Babel，如果我们不想的话，我们不必编写CJS：我们仍然可以使用ES模块，并在运行测试时即时将其转换！ 这就是我能够在import包含模块而不是require并且仍然具有可以正常运行的测试。
伊斯坦布尔和工作服 (Istanbul and Coveralls)
Writing unit tests is great, but as your project scales, you may lose track of what needs to be tested. It’s not your fault: you’re busy building something and there are a lot of things to remember. That’s why we automate tasks, to assist ourselves and help us remember things we forget. Code coverage monitors your code on a regular basis (usually every time you run tests) and gives you a report of the amount of code that’s covered by unit tests.
编写单元测试很棒，但是随着项目的扩展，您可能会失去对需要测试的内容的跟踪。 这不是您的错：您正在忙于构建某些东西，还有很多事情要记住。 这就是为什么我们使任务自动化，帮助自己并帮助我们记住我们忘记的事情的原因。 代码覆盖率会定期监视您的代码(通常是每次运行测试时)，并为您提供单元测试所覆盖的代码量的报告。
Istanbul is a code coverage tool. In Dinero.js I use nyc, its command-line interface, to generate reports.
伊斯坦布尔是一个代码覆盖率工具。 在Dinero.js中，我使用其命令行界面nyc生成报告。
Istanbul generates reports in all kinds of formats: terminal output, HTML, but also LCOV. This one is particularly useful when used with online services like Coveralls. Every time Travis CI runs a build, it executes tests and nyc generates an LCOV file. It’s then sent to Coveralls which generates detailed stats. This is particularly useful for contributions: when someone submits a pull request, a Coveralls bot automatically replies with the updated coverage. This contributes to making code reviews easier and quicker.
Istanbul生成各种格式的报告：终端输出，HTML以及LCOV 。 与Coverovers等在线服务一起使用时，这一功能特别有用。 特拉维斯CI每次运行构建时，都会执行测试，并且nyc会生成LCOV文件。 然后将其发送到Coveralls，以生成详细的统计信息。 这对于贡献特别有用：当有人提交请求请求时，Coveralls机器人会自动回复更新的承保范围。 这有助于使代码审查更容易，更快捷。
建立 (Build)
巴别塔 (Babel)
ES6+ has brought amazing features to JavaScript, but they’re still not supported everywhere. This doesn’t mean you must wait before you can start to use it: meet Babel.
ES6 +为JavaScript带来了惊人的功能，但仍未在所有地方都支持它们。 这并不意味着您必须等待才能开始使用它：与Babel见面。
Babel is a transpiler. It translates code into another language or another version of the same language. Your source code remains the same, but what the user gets is translated into another syntax to ensure it works in their environment. You get to use cutting-edge features, neat syntaxes and keep your source code clean, and you don’t have to worry about it working on old browsers.
巴别是一个译者 。 它将代码翻译成另一种语言或同一语言的另一种版本 。 您的源代码保持不变，但是用户获得的内容将转换为另一种语法，以确保其可在其环境中正常工作。 您可以使用最先进的功能，简洁的语法并保持源代码的整洁，而不必担心它在旧的浏览器上无法正常工作。
I’ve written the entire Dinero.js source code using ES6 features, such as fat arrow functions and ES modules. Every time I release a version, Babel transpiles the source files into distributable ES5 code.
我已经使用ES6功能(例如粗箭头功能和ES模块)编写了整个Dinero.js源代码。 每次发布版本时，Babel都会将源文件转换为可分发的ES5代码。
Babel also comes handy for unit testing. I’m using Node.js for that, which doesn’t natively support ES modules yet, thus can’t handle my source files. Thanks to Babel, I can transpile them on the fly every time I run my test command.
Babel还方便进行单元测试。 我正在为此使用Node.js，它本身还不支持ES模块，因此无法处理我的源文件。 多亏了Babel，每当我运行测试命令时，我都可以即时移植它们。
卷起 (Rollup)
Once your library is ready, you need to package it so it can be used by different people in different environments. Some will use it with Node. Some will need it directly in the browser as a script tag. Others will want it as an ES module to be included it in their own project and bundled with their own tools.
库准备就绪后，您需要对其进行打包，以便供不同环境中的不同人员使用。 有些人将其与Node一起使用。 有些人会直接在浏览器中将其作为脚本标签使用。 其他人希望将其作为ES模块包含在自己的项目中，并与自己的工具捆绑在一起。
Rollup is a module bundler like Webpack or Parcel, but it’s particularly useful for building JavaScript libraries. It was designed to work with ES modules, and turn them into any module format you want.
汇总是类似于Webpack或Parcel的模块捆绑程序，但是对于构建JavaScript库特别有用。 它旨在与ES模块一起使用，并将其转换为所需的任何模块格式。
Back in the days, the code we wrote was exactly the code that ended up in production. If you wanted your code to be as ubiquitous as possible, you’d wrap it into a UMD pattern by hand. Today, you can code exactly the way you want and ship different bundles for everyone, thanks to module bundlers like Rollup. Need a UMD version? There you go. Along with an AMD, a CJS, an IIFE, anything.
过去，我们编写的代码正是最终在生产中使用的代码。 如果您希望代码尽可能地无处不在，则可以手动将其包装为UMD模式。 如今，借助像Rollup这样的模块打包器，您可以完全按照所需的方式进行编码并为每个人运送不同的捆绑包。 需要UMD版本吗？ 妳去 连同AMD ， CJS ， IIFE等等 。
CI (CI)
的GitHub (GitHub)
The most popular collaborative open source platform needs no introduction. GitHub is a wonderful product that fulfills everything developers can hope for and beyond. It hosts most of my projects. It hosts this blog. It connects with the best CI tools on the market. If you want to contribute to your favorite open source projects, build yourself a reputation and create the next best tools for other developers, look no further.
最受欢迎的协作开源平台无需介绍。 GitHub是一个很棒的产品，可以满足开发人员可以期望甚至超越的一切。 它托管了我的大部分项目。 它托管此博客。 它与市场上最好的CI工具连接。 如果您想为自己喜欢的开源项目做出贡献，建立自己的声誉，并为其他开发人员创建次佳工具，那就别无所求。
特拉维斯CI (Travis CI)
You can look at Travis CI as the conductor of your project’s build process.
您可以将Travis CI视为项目构建过程的引导者。
Crafting a quality project is hard, and coding is only a small part of it. There are tasks to run in a certain order, at the right time, under the right circumstances. Here’s a list of all that needs to be done once I want to ship anything for Dinero.js:
编写高质量的项目很困难，而编码只是其中的一小部分。 在正确的环境下，在正确的时间以正确的顺序运行任务。 这是我要为Dinero.js交付任何东西后需要完成的所有工作的列表：
Run unit tests. If they pass:
运行单元测试。 如果通过 ：
- Run code coverage 运行代码覆盖率
- Build a version (dist files) 生成版本(dist文件)
- Recompile the docs 重新编译文件
- Tag a version and push the tag on GitHub 标记版本并在GitHub上推送标记
- Increment the version and push the build to npm 增加版本并将构建推送到npm
- Write an entry in the changelog 在变更日志中写一个条目
- Push the docs files to GitHub Pages 将文档文件推送到GitHub Pages
Otherwise, fix things, rinse and repeat.
否则 ，请修理东西，冲洗并重复。
Before I installed my CI pipeline, I tried doing this by hand. Guess what? There hasn’t been a single time when I did it right. Why? Because as a typical human, I’m error-prone and subject to distractions. On the other hand, machines respond well to orders. They will do exactly what you want, how you want it. All you have to do is specify it well, once.
在安装CI管道之前，我尝试手动进行此操作。 你猜怎么了？ 我没有一次做对了。 为什么？ 因为作为一个典型的人，我很容易出错并且容易分心。 另一方面，机器对订单React良好。 他们将完全按照您的要求做您想做的事。 您所要做的就是一次指定好它。
Travis CI is free for open-source projects and integrates well with third-party services. All you have to do is log in with your GitHub account and sync a project. By default, Travis will execute tests every time you push to your remote repository. Then, you can tell Travis what to do when tests pass with a .travis.yml file at the root of the project.
Travis CI对于开源项目是免费的，并且可以与第三方服务很好地集成。 您要做的就是使用您的GitHub帐户登录并同步项目。 默认情况下，每次您推送到远程存储库时，Travis都会执行测试。 然后，您可以告诉Travis当测试通过项目根目录下的.travis.yml文件时该怎么做 。
语义释放 (semantic-release)
Before getting into what semantic-release does, you need to understand Semantic Versioning (aka “semver”).
在了解语义发布之前，您需要了解语义版本控制 (又名“ semver”)。
In short, semver is a convention based on an X.Y.Z numeric format, respectively the MAJOR, the MINOR and the PATCH:
简而言之，semver是一种基于XYZ数字格式的约定，分别是MAJOR，MINOR和PATCH：
- When you fix a bug but your changes are backwards compatible, you increment the PATCH. 修复错误但更改向后兼容时，可以增加PATCH。
- When you add a feature but your changes are still backwards compatible, you increment the MINOR. 当您添加功能但更改仍然向后兼容时，您可以增加MINOR。
- When you make any kind of backwards incompatible changes, you increment the MAJOR. 当您进行任何类型的向后不兼容更改时，可以增加MAJOR。
This helps people who depend on your project know if they can safely upgrade, and simplifies dependency management in general.
这可以帮助依赖您项目的人员知道他们是否可以安全升级，并且通常可以简化依赖关系管理。
Semantic Versioning is widely used in software development, but it can be hard to enforce. Again, we humans are error-prone and sentimental creatures. If you forget to take a commit into account, have a doubt on the nature of a change, or simply don’t understand semver quite yet, you can mislabel a new version. If you fix a small bug that slipped your attention just after releasing a new version, you might be tempted to sneak it in and act like nothing happened. This is where semantic-release comes into play.
语义版本控制在软件开发中被广泛使用，但是可能难以执行。 再说一遍，我们人类是容易出错和感性的生物。 如果您忘记考虑提交，对更改的性质有疑问，或者只是根本不了解semver，则可以将新版本贴错标签。 如果您修复了一个小错误，但该错误在发布新版本后立即引起了您的注意，则您可能会想将其潜入其中，并且好像什么都没有发生。 这就是语义释放发挥作用的地方。
In short, semantic-release takes care of versioning for you. You have no say in it. It uses your conventionally written commit messages to decide what the next version will be. Add it to your CI pipeline (in your Travis CI workflow, for example), and you get a fully automated system that will read your commits, change the version, tag it, push to GitHub, push to npm, and write your changelog. Phew.
简而言之，语义发布会为您处理版本控制 。 你没有发言权。 它使用您常规编写的提交消息来确定下一个版本。 将其添加到您的CI管道(例如，在Travis CI工作流中)，您将获得一个完全自动化的系统，该系统将读取您的提交，更改版本，对其进行标记，推送到GitHub，推送到npm并编写您的变更日志。 ew
不是很多吗 (Isn’t it a bit much?)
This may look like a lot of things to set up. “Do I really need all this?” you may wonder. I’ll reply with a few questions: how many tasks are you currently handling by hand? How much time does a release take you? How confident are you when you do it? When was the last time you performed your entire workflow without forgetting anything?
这可能看起来需要进行很多设置。 “我真的需要所有这些吗？” 你可能想知道。 我会回答几个问题：您目前正在手动处理多少个任务？ 发布需要多少时间？ 您这样做时有多自信？ 您上一次执行整个工作流程时没有忘记什么？
I personally can’t deploy a release by hand without a cheat sheet. Linting, formatting, testing, code coverage, docs, building, semantic versioning, releasing, updating the changelog, all in that order while making sure I’m on the right branch… ugh. Really hope I didn’t leave a typo! This process is so time-consuming, you can screw it up in so many ways, and it’s repeatedly taking you so much time from actual work, that automating it should be a no-brainer.
如果没有备忘单，我个人无法手动部署发布。 整理，格式化，测试，代码覆盖率，文档，构建，语义版本控制，发布，更新变更日志，所有这些都按此顺序进行，同时确保我在正确的分支上……。 真的希望我没有留下错字！ 这个过程非常耗时，您可以通过多种方式来解决问题，并且重复地花费了您大量的实际工作时间，因此自动化它应该是不费吹灰之力的 。
It looks tricky when you’re not used to it, but once you’ve built your workflow, all you have to do is maintain it. Update dependencies, keep an eye on innovative new tools, improve the process. You can even use a scaffolding tool to save your whole configuration and deploy ready-to-use project templates. Give it a try!
当您不习惯它时，它看起来很棘手，但是一旦构建了工作流，您要做的就是维护它。 更新依赖关系，关注创新的新工具，改善流程。 您甚至可以使用脚手架工具来保存整个配置并部署即用型项目模板。 试试看！
What about you? What’s your workflow for web projects? What has made your life easier? Come chat with me about it on Twitter!
你呢？ 您的Web项目工作流程是什么？ 是什么让您的生活更轻松？ 在Twitter上与我聊天吧！
Also, you can check out more of my articles on my blog.
开源javascript库