华为开源构建工具

I recently published a package on npm: a data structures and algorithms library implemented in JavaScript.

我最近在npm上发布了一个软件包：用JavaScript实现的数据结构和算法库。

The purpose of the project is to help others learn and understand data structures and algorithms from a JavaScript perspective.

该项目的目的是帮助其他人从JavaScript的角度学习和理解数据结构和算法。

Rather than containing only snippets of code with accompanying explanations, the project is meant to provide an eager learner with fully working code, good test cases, and a playground full of examples.

该项目不是只包含代码片段及其附带的说明，而是旨在为渴望的学习者提供完整的代码，良好的测试用例以及充满示例的游乐场。

If you’re interested, the project can be found on npm here.

如果您有兴趣，可以在npm 此处找到该项目。

But, rather than talking about the project itself, what I want to write about today are all the neat tools I learned about and used while creating the project.

但是，我今天要写的不是谈论项目本身，而是我在创建项目时学习和使用的所有巧妙工具。

I’ve worked on tons of side projects and demos over the last six years, but each of them are very visibly just "pet projects". They in no way have the qualities that’d make them look professional or production-ready.

在过去的六年中，我从事了大量的附带项目和演示，但每个项目显然都是“宠物项目”。 他们绝不具备使他们看起来专业或可以投入生产的素质。

What I set out to create was something that could be considered a respectable open-source package. To do that, I decided my project would need proper documentation, tooling, linting, continuous integration, and unit tests.

我着手创建的东西可以被认为是一个受人尊敬的开源软件包。 为此，我决定我的项目将需要适当的文档，工具，整理，连续集成和单元测试。

Below are some of the tools I used. Each one serves a unique purpose. I’ve linked to the documentation for each package so you, too, can start utilizing these tools in projects of you own.

以下是我使用的一些工具。 每个人都有其独特的目的。 我已经链接到每个软件包的文档，因此您也可以在自己的项目中开始使用这些工具。

Note: This article assumes that you are already familiar with the process of creating a simple JavaScript package and publishing it on npm.

注意 ：本文假定您已经熟悉创建简单JavaScript程序包并将其发布到npm的过程。

If not, the npm team has some great documentation on getting started that will walk you through the initialization of a project and the steps for publishing.

如果没有，npm团队会提供一些很好的入门文档，这些文档将引导您完成项目的初始化和发布步骤。

So let's get started.

因此，让我们开始吧。

更漂亮 (Prettier)

Prettier is an opinionated code formatter that automatically formats your code for you. Rather than simply using ESLint to enforce whatever formatting standards your team has agreed on, Prettier can take care of the formatting for you.

Prettier是一个自以为是的代码格式化程序，可以自动为您格式化代码。 Prettier不仅可以使用ESLint来执行团队已同意的任何格式标准，还可以为您处理格式。

No more worrying about fixing your indentation and line widths! I’m using this specifically for my JavaScript, but it can handle many different languages.

不必担心固定缩进和线宽！ 我专门针对我JavaScript使用它，但是它可以处理许多不同的语言。

You can check out the Prettier docs here: https://github.com/prettier/prettier

您可以在此处查看Prettier文档： https : //github.com/prettier/prettier

Stylelint (stylelint)

stylelint autoformats your CSS for you. Similar to Prettier, this tool helps you keep your CSS clean while taking care of the heavy lifting for you.

stylelint为您自动格式化CSS。 与Prettier相似，此工具可帮助您保持CSS整洁，同时还能为您处理繁重的工作。

You can check out the stylelint docs here: https://github.com/stylelint/stylelint

您可以在此处查看stylelint文档： https : //github.com/stylelint/stylelint

ESLint (ESLint)

ESLint handles all my other JavaScript linting for catching syntax errors and enforcing best practices.

ESLint处理我所有的其他JavaScript lint，以捕获语法错误并实施最佳实践。

You can check out the ESLint docs here: https://eslint.org/

您可以在此处查看ESLint文档： https ://eslint.org/

市民 (Commitizen)

Commitizen is a CLI tool that walks you through writing your commit messages. It generates the commit message for you based on your input and ensures that the resulting commit message follows the Conventional Commits standard.

Commitizen是一个CLI工具，可引导您逐步编写提交消息。 它根据您的输入为您生成提交消息，并确保生成的提交消息符合“常规提交”标准。

You can check out the Commitizen docs here: https://github.com/commitizen/cz-cli

您可以在此处查看Commitizen文档： https : //github.com/commitizen/cz-cli

犯错 (commitlint)

commitlint verifies that your commit messages follow the Conventional Commits standard. As long as you use Commitizen to create your commit messages, you won’t run into any problems.

commitlint验证您的提交消息是否符合常规提交标准。 只要您使用Commitizen创建提交消息，就不会遇到任何问题。

The real benefit of using commitlint is to catch commits that developers wrote on their own that don’t follow your formatting standards.

使用commitlint的真正好处是可以捕获开发人员自己编写的，不遵循您的格式化标准的提交。

You can check out the commitlint docs here: https://github.com/conventional-changelog/commitlint

您可以在此处查看commitlint文档： https : //github.com/conventional-changelog/commitlint

皮棉阶段 (lint-staged)

lint-staged runs linters against code that you’re trying to commit. This is where you can validate that your code is passing the standards being enforced by Prettier, stylelint, and ESLint.

lint-staged对您要提交的代码运行linters。 在这里，您可以验证代码是否通过了Prettier，stylelint和ESLint强制执行的标准。

You can check out the lint-staged docs here: https://github.com/okonet/lint-staged

您可以在此处查看lint暂存的文档： https : //github.com/okonet/lint-staged

沙哑 (Husky)

Husky makes it easy to run Git hooks.

Husky使运行Git挂钩变得容易。

All the previously mentioned tools can be run through Husky on Git hooks like pre-commit or commit-msg, so this is where the magic happens.

所有前面提到的工具都可以在Husky上的Git钩子上运行，例如pre-commit或commit-msg ，这就是神奇的地方。

For instance, I’m running lint-staged and my unit tests during the pre-commit hook, and I’m running commitlint during the commit-msg hook. That means when I’m trying to check in my code, Husky does all the validation to make sure I’m abiding by all the rules I’m enforcing in my project.

例如，我在pre-commit挂钩期间运行lint-staged并进行单元测试，而在commit-msg挂钩期间运行commitlint。 这意味着当我尝试检入代码时，Husky将进行所有验证，以确保我遵守在项目中执行的所有规则。

You can check out the Husky docs here: https://github.com/typicode/husky

您可以在此处查看Husky文档： https : //github.com/typicode/husky

卷起 (Rollup)

Rollup is a module bundler for JavaScript. It takes all of your source code and bundles it into the files you actually want to distribute as part of your package.

汇总是JavaScript的模块捆绑程序。 它获取所有源代码，并将其捆绑到您实际要作为软件包一部分分发的文件中。

The conventional wisdom seems to be if you’re building a web application, you should use webpack. And if you’re building a library, you should use Rollup.

传统的观点似乎是，如果您要构建Web应用程序，则应使用webpack。 而且，如果要构建库，则应使用汇总。

In my case, I was building a data structures and algorithms library, so I chose to use Rollup. One benefit seems to be the output that Rollup generates is significantly smaller than what webpack outputs.

就我而言，我正在构建数据结构和算法库，因此我选择使用汇总。 好处之一似乎是Rollup生成的输出明显小于Webpack的输出。

You can check out the Rollup docs here: https://rollupjs.org/guide/en/

您可以在此处查看汇总文档： https : //rollupjs.org/guide/zh/

标准版本 (Standard Version)

Standard Version helps automate your versioning and changelog generation.

标准版本可帮助自动执行版本控制和更改日志生成。

Previously, I mentioned tools like Commitizen and commitlint for formatting your commits according to the Conventional Commits standard. Why, you may ask, is that helpful?

之前，我提到过诸如Commitizen和commitlint之类的工具，用于根据常规的Commits标准来格式化您的提交。 您可能会问，为什么有帮助？

The answer, at least in part, is that by using a consistent commit message format, you can use tools that are able to understand what kind of changes your commits are making.

答案至少部分是通过使用一致的提交消息格式，您可以使用能够了解您的提交进行何种更改的工具。

For example, are you fixing bugs? Adding new features? Making breaking changes people consuming your library should be aware of? Standard Version is able to understand your commit messages and then generate a changelog for you.

例如，您要修复错误吗？ 添加新功能？ 做出重大更改的人们应该注意使用您的库的情况？ 标准版能够理解您的提交消息，然后为您生成一个变更日志。

It’s also able to intelligently bump the version of your package according to the semantic versioning standard (major, minor, patch).

它还能够根据语义版本控制标准(主要，次要，补丁)智能地更改软件包的版本。

You can check out the Standard Version docs here: https://github.com/conventional-changelog/standard-version

您可以在此处查看标准版文档： https : //github.com/conventional-changelog/standard-version

特拉维斯CI (Travis CI)

Travis CI is a continuous-integration (CI) tool that can be integrated with GitHub, where my code happens to be hosted.

Travis CI是一个持续集成(CI)工具，可以与GitHub集成，而我的代码恰好托管在GitHub中。

CI tools are important because they allow your commits to be tested yet again before you merge them into your master branch. You could argue using Travis CI and a tool like Husky duplicates functionality, but it’s important to keep in mind that even Husky can be bypassed by passing a --no-verify flag to your commit command.

CI工具非常重要，因为它们允许您在再次将提交合并到master分支之前再次对其进行测试。 您可能会争论使用Travis CI和诸如Husky之类的工具来复制功能，但是要记住，甚至可以通过在提交命令中传递--no-verify标志来绕过Husky。

Through GitHub, you can specify that your Travis CI jobs must be passing before code can be merged, so this adds one more layer of protection and verifies that only passing code makes it into your repo.

通过GitHub，您可以指定必须先通过Travis CI作业，然后才能合并代码，这样可以增加一层保护，并验证只有通过代码才能将其纳入您的存储库。

You can check out the Travis CI docs here: https://docs.travis-ci.com/

您可以在此处查看Travis CI文档： https : //docs.travis-ci.com/

Codecov (Codecov)

Codecov is another CI tool that looks at your project’s code coverage.

Codecov是另一种CI工具，用于查看项目的代码覆盖率。

I’m writing JavaScript unit tests using Jest. Part of my Travis CI job runs my test suite and ensures they all pass. It also pipes the code coverage output to Codecov, which then can verify if my code coverage is slipping or staying high. It also can be used in conjunction with GitHub badges, which we’ll talk about next.

我正在使用Jest编写JavaScript单元测试。 Travis CI作业的一部分运行我的测试套件，并确保它们全部通过。 它还将代码覆盖率输出输出到Codecov，后者可以验证我的代码覆盖率是否下降或保持较高水平。 它也可以与GitHub徽章结合使用，我们将在下面讨论。

You can check out the Codecov docs here: https://docs.codecov.io/docs

您可以在此处查看Codecov文档： https ://docs.codecov.io/docs

徽章 (Badges)

Have you ever looked at a project in GitHub and seen little badges near the top of the README? Things like whether the build is passing, what the code coverage is, and what the latest version of the npm package is can all be shown using badges.

您是否曾经在GitHub上查看过一个项目，并且在README顶部附近看到过小徽章？ 诸如构建是否通过，代码覆盖率以及npm软件包的最新版本之类的内容都可以使用标记显示。

They’re relatively simple to add, but I think they add a really nice touch to any project. Shields.io is a great resource for finding lots of different badges that can be added to your project, and it helps you generate the markdown to include in your README.

它们的添加相对简单，但是我认为它们可以为任何项目添加非常好的外观。 Shields.io是查找许多可以添加到您的项目中的不同标志的重要资源，它可以帮助您生成降价标记以包含在自述文件中。

You can check out the Shields.io docs here: https://shields.io/

您可以在此处查看Shields.io文档： https ://shields.io/

文献资料 (Documentation)

A little documentation goes a long way. In my project, I’ve added a README, CHANGELOG, contributing guidelines, code of conduct, and a license.

少量文档可以帮助您。 在我的项目中，我添加了自述文件，CHANGELOG，贡献准则，行为准则和许可证。

These docs serve to help people know what your project is, how to use it, what changes have been made with each release, how to contribute if they want to get involved, how they’re expected to interact with other members of the community, and what the legal terms are.

这些文档可帮助人们了解您的项目是什么，如何使用它，对每个发行版进行了哪些更改，如果他们想参与其中如何做出贡献，期望他们如何与社区的其他成员进行互动，以及法律条款是什么。

You can check out the documentation for my project here: https://github.com/thawkin3/js-data-structures-and-algorithms

您可以在这里查看我的项目的文档： https : //github.com/thawkin3/js-data-structures-and-algorithms

GitHub模板 (GitHub Templates)

Did you know you can create templates in GitHub for things like bug reports, feature requests, and pull requests? Creating these templates makes it crystal clear, for example, what information someone should be expected to provide when filing a bug.

您是否知道可以在GitHub中为错误报告，功能请求和提取请求等创建模板？ 创建这些模板可以使您一目了然，例如，在提交错误时应该期望某人提供哪些信息。

You can check out the GitHub templates docs here: https://help.github.com/en/github/building-a-strong-community/about-issue-and-pull-request-templates

您可以在此处查看GitHub模板文档： https : //help.github.com/en/github/building-a-strong-community/about-issue-and-pull-request-templates

闭幕 (Closing)

That’s it. When I first showed this project to some friends, one of them commented, “Oh my build tool soup!” And he may be right. This is a lot. But I strongly believe that adding all the tooling above is worth it. It helps automate many things and helps keep your codebase clean and in working order.

而已。 当我第一次向一些朋友展示这个项目时，其中一个评论说：“哦，我的构建工具汤！” 他可能是正确的。 好多 但是我坚信添加以上所有工具是值得的。 它有助于自动化许多事情，并有助于保持代码库的清洁和正常运行。

My biggest takeaway from building this project is that setting up all of the tooling above isn’t as daunting as it may seem. Each of these tools has good documentation and helpful guides for getting started. It really wasn’t that bad, and you should feel confident adopting some (if not all) of these tools in your project, too.

构建该项目的最大收获是，设置上面的所有工具并不像看上去那样令人生畏。 这些工具中的每一个都有良好的文档和有用的入门指南。 确实还不错，并且您应该对在项目中采用其中一些(如果不是全部)工具充满信心。

Happy coding!

编码愉快！

翻译自: https://www.freecodecamp.org/news/effective-tools-for-your-open-source-javascript-project/

华为开源构建工具