在将NPM软件包添加到项目中之前要问什么

by Jacob Worrel

雅各布·沃雷尔(Jacob Worrel)

在将NPM软件包添加到项目中之前要问什么 (What to ask yourself before adding an NPM package to your project)

One of the greatest things about being a JavaScript developer today is the ability to leverage its incredibly rich ecosystem. With almost a million packages on the NPM registry, it’s not uncommon to reach for an off-the-shelf solution when facing a commonly solved problem. The less time you spend reinventing the wheel, the more you can focus on the larger problem at hand.

如今，成为JavaScript开发人员最伟大的事情之一就是能够利用其极其丰富的生态系统。 NPM注册表中有近一百万个软件包，因此，面对一个通常可以解决的问题时，找到现成的解决方案并不少见。 重新设计轮子的时间越少，您就可以将更多的精力放在手头的更大问题上。

That being said, not all open source is created equal and it’s probably a good idea to do your homework before taking the leap and depending on someone else’s code. Here are some basic questions you should ask yourself before adding a new NPM package to your project, and the tools you can use to answer them.

话虽这么说，并不是所有开放源代码都是一样的，在跳远并依赖于其他人的代码之前做功课可能是个好主意。 在将新的NPM程序包添加到项目中之前，您应该问自己以下一些基本问题，以及可以用来回答这些问题的工具。

TL; DR (TL;DR)

The following questions are based on my experience as a JavaScript developer and are by no means exhaustive. If you think anything’s missing, please feel free to let me know in the comments!

以下问题是基于我作为JavaScript开发人员的经验得出的，绝不是详尽无遗的。 如果您认为缺少任何内容，请随时在评论中让我知道！

How popular is it? Look at weekly downloads on NPM & stars on Github.

它有多受欢迎？ 查看NPM上的每周下载量以及Github上的星级。

How mature is it? Look at the date of the first published version on NPM and the number of open issues vs. closed issues on Github.

有多成熟？ 查看有关NPM的第一个发行版本的日期以及Github上未解决问题与未解决问题的数量。

Is it actively maintained? Look at the commit history and the Commits and Code Frequency charts (under the Insights tab) on Github. Check the “last published” date on NPM.

是否积极维护？ 查看Github上的提交历史记录以及“ 提交和代码频率”图表(在“见解”选项卡下)。 检查NPM上的“最后发布”日期。

How big is it? Check bundle size on Bundlephobia.

它有多大？ 在Bundlephobia上检查束的大小。

Does it have test coverage? Check for coverage badges on NPM/Github. Open up the test files.

有测试范围吗？ 检查NPM / Github上的覆盖标志。 打开测试文件。

它有多受欢迎？ (How popular is it?)

Popularity is probably the first thing most people want to know when looking around for an open source package to solve their problem — more specifically, how many stars it has on Github and how many weekly downloads it’s getting on NPM.

流行可能是大多数人在寻找开源软件包来解决他们的问题时首先要知道的事情-更具体地说，它在Github上有多少颗星，以及在NPM上有多少每周的下载量。

And while these two metrics might give you a pulse on how much traction a project has within the community, you should definitely take these numbers with a grain of salt. Keep in mind that a Github star is basically the equivalent to a “like” on social media sites and a lot of developers will dish these out like candy. I’m guilty of this myself, and just because I’ve starred a repo doesn’t mean I’ve checked for code quality and given it my full endorsement.

尽管这两个指标可能会让您对项目在社区中的影响力有一定的了解，但您绝对应该对这些数字有所了解。 请记住，Github明星基本上等同于社交媒体网站上的“赞”，并且许多开发人员都会像糖果一样抛出这些。 我对此感到内,，仅因为我出了一个回购协议并不意味着我已经检查了代码质量并得到了我的完全认可。

When it comes to downloads, even NPM admits their stats are “naive by design” since they include downloads by automated build servers, mirrors and bots. Still, you have to start somewhere so you might as well get this question out of the way. Just be aware this is probably the least important (and often the most misleading!) factor, so make sure to do your due diligence and definitely don’t stop there.

在下载方面，甚至NPM都承认其统计数据“ 天真地设计 ”，因为它们包括自动构建服务器，镜像和机器人的下载。 不过，您必须从某个地方开始，这样您就可以很好地解决这个问题。 请注意，这可能是最不重要的因素(通常是最容易引起误解的因素)，因此请确保进行尽职调查，并且绝对不要就此止步。

有多成熟？ (How mature is it?)

If you’ve heard of the 80/20 rule, you’re probably familiar with the concept that the first 80% of code is typically done in 20% of the time, and the remaining 20% takes the other 80% of the time. This is because it’s usually easy to get something up and running, but handling all the edge cases, fixing unforeseen bugs and dealing with performance and scale is often the most challenging part of writing stable software. This is why you ideally only want to use open source that has been battle tested and has withstood the test of time.

如果您听说过80/20规则 ，则可能对以下概念很熟悉：前80％的代码通常在20％的时间内完成，而其余20％的代码则在80％的时间内完成。 这是因为通常很容易启动并运行某些东西，但是处理所有极端情况，修复无法预见的错误以及处理性能和规模通常是编写稳定软件最具挑战性的部分。 因此，理想情况下，您只想使用经过实战检验并经受住时间考验的开源。

The first thing to check is when a package was first published. Go to the project’s NPM page, click on the Versions tab to get the full history of every release and scroll down to the very bottom. A long history with lots of releases is usually a good sign since it means the project has been iterated on over time.

首先要检查的是软件包首次发布的时间。 转到项目的NPM页面，单击“版本”选项卡以获取每个发行版的完整历史记录，然后向下滚动至最底部。 具有许多版本的悠久历史通常是一个好兆头，因为这意味着该项目已经随着时间的推移而反复进行。

The next and probably best indicator of a mature project is the number of open and closed issues on Github. It’s usually a good idea to look at these two numbers together since one doesn’t really mean all that much without the other. A high number of open issues isn’t necessarily a bad thing if the number of closed issues is even higher. To give you some frame of reference, as of this writing, React has about 400 open issues but more than 6500 closed. Node.js has around 600 open issues and almost 9000 closed.

一个成熟项目的下一个指标，也许是最好的指标，是Github上未解决和未解决的问题的数量。 通常将这两个数字放在一起考虑是一个好主意，因为没有另一个就没有那么多意义。 如果未解决问题的数量甚至更多，那么大量未解决问题并不一定是一件坏事。 为了给您一些参考，在撰写本文时， React有大约400个未解决的问题，但有6500多个已结束。 Node.js大约有600个未解决的问题，近9000个已关闭。

There’s no magic ratio but beware of any project with a high number of open issues relative to how many issues have been closed. On the flip side, a low number of open issues isn’t necessarily a good thing if the number of closed issues is low as well. This likely means it hasn’t been used very much and is still in an early stage of development.

没有魔术般的比率，但是要提防相对于已关闭的问题数量众多的未解决问题的项目。 另一方面，如果未解决问题的数量也很少，那么未解决问题的数量不一定是一件好事。 这可能意味着它还没有被广泛使用并且仍处于开发的早期阶段。

是否积极维护？ (Is it actively maintained?)

Unless, a project is already very mature and not adding new features, or does something relatively small in scope, it’s important that it’s actively maintained. Remember the 80/20 rule? The only way software goes from new and experimental to stable and mature is through active maintenance, meaning regular bug fixes and added enhancements.

除非项目已经非常成熟并且没有添加新功能，或者所做的事情范围相对较小，否则必须积极维护它。 还记得80/20规则吗？ 软件从新的和试验性的到稳定和成熟的唯一途径是主动维护，这意味着要定期修复错误并添加增强功能。

In my experience, the best way to check for this is by looking at the commit history on the project’s master branch. First, click on the number of commits on the project’s Github page and check when the last commit was merged to master. This date doesn’t mean very much by itself but it’s an important piece of the overall picture.

以我的经验，最好的检查方法是查看项目的master分支上的提交历史记录。 首先，在项目的Github页面上单击提交次数，然后检查最后一次提交何时合并到master。 这个日期本身并不意味着什么，但它是整个情况的重要组成部分。

If you’re like me and you prefer to see this kind of data visualized, click on the insights tab, where you can glean all sorts of information about the repo. I could probably write an entire blog post about this feature alone, so all I’m going to say is, if you haven’t used this yet, stop reading, go to your favorite open source project’s Github page and start playing around with it.

如果您像我一样，并且希望将这种数据可视化，请单击“见解”选项卡，您可以在其中收集有关回购协议的各种信息。 我可能只写一篇有关此功能的完整博客文章，所以我要说的是，如果您还没有使用它，请停止阅读，转到您最喜欢的开源项目的Github页面并开始使用它。

I particularly like the Commits and Code Frequency graphs since they tell me at a glance how much the project is being worked on. Remember though, just because there aren’t a lot of recent commits doesn’t mean the code can’t be trusted. On the contrary, this is sometimes a sign of maturity — in the screenshot above, the code frequency chart for Express is a great visualization for what a mature project looks like.

我特别喜欢“ 提交”和“代码频率”图，因为它们一眼就能告诉我项目正在进行的工作量。 但是请记住，仅仅因为最近提交的次数不多并不意味着该代码不能被信任。 相反，有时这是成熟的标志-在上面的屏幕截图中，Express的代码频率图很好地展示了一个成熟的项目。

Last but not least, I find it useful to know when a new version was last published on NPM, which is included in the hero stats on a project’s NPM page. This gives me a general sense as to how often the maintainers are actually scheduling releases, versus just committing code.

最后但并非最不重要的一点是，我发现了解何时在NPM上发布新版本很有用，该新版本包含在项目NPM页面上的英雄统计中。 这使我对维护者实际调度发布而不是提交代码的频率有了大致的了解。

它有多大？ (How big is it?)

No one likes a bloated bundle. And while it’s easy to keep adding node modules to a project, this can come at a cost. Minification, compression, and code splitting helps a lot, but at the end of day, it all boils down to how much JavaScript you’re sending to the client.

没有人喜欢a肿的捆绑包。 尽管很容易将节点模块添加到项目中，但这可能要付出一定的代价 。 缩小，压缩和代码拆分有很大帮助，但归根结底，这都归结为您要向客户端发送多少JavaScript。

My go to resource for this is Bundlephobia, a wonderful site that not only shows you the bundle size of an NPM package, but all sorts of other fancy things. Pictured above, you can see the estimated download time on slow networks, the evolution of the bundle size over the course of different versions, and the composition of dependencies. It will also tell you if the package is optimized to leverage tree-shaking with modern bundlers like Webpack, and even suggests similar modules, with stats comparing how they stack up size-wise!

我在此获得的资源是Bundlephobia ，这是一个很棒的网站，它不仅向您显示NPM软件包的捆绑包大小，而且还向您展示其他各种花哨的东西。 如上图所示，您可以看到慢速网络上的估计下载时间，不同版本中捆绑包大小的变化以及依赖项的组成。 它还会告诉您该程序包是否经过优化，可以利用Webpack等现代捆绑程序利用摇树，甚至可以建议类似的模块，并通过统计数据比较它们如何按大小堆叠！

Ideally, you want to use modules with a small size and a low number of dependencies, if any. Of course, size is relative so make sure you’re comparing apples to apples — if you’re looking at a charting library, for example, make sure you’re comparing it to other charting libraries (which tend to be on the bigger end of the spectrum).

理想情况下，您希望使用较小的模块和较少的依赖项(如果有)。 当然，大小是相对的，因此请确保您将苹果与苹果进行比较-例如，如果您正在查看图表库，请确保将其与其他图表库进行比较(往往比较大)的频谱)。

有测试范围吗？ (Does it have test coverage?)

This may seem obvious but always, always, always check for test coverage. Code you can’t test is code you can’t trust.

这似乎很明显，但始终，始终，始终检查测试覆盖率。 您无法测试的代码就是您无法信任的代码。

Nowadays, it’s much easier to get a high level picture of coverage thanks to tools like Coveralls and Codecov— which track coverage over time and provide authors with shiny badges they can proudly display on their Github and NPM pages. Bear in mind though that test coverage tools only check how much code executed during tests and can be misleading at times. If you really want to get down into the nitty-gritty, there’s no substitute for opening up the test files and reading through the test specs.

如今，它更容易获得感谢覆盖率高的水平图片一样的工具工作服和Codecov -其轨道覆盖范围时间，并提供作者与闪亮的肩章，他们可以在他们的Github上和NPM页骄傲地展示。 请记住，尽管测试覆盖率工具仅检查在测试期间执行了多少代码，并且有时可能会误导您 。 如果您真的想深入研究，那么打开测试文件并阅读测试规范是无可替代的。

而且当然… (And of course…)

它是否遵循语义版本控制？ (Does It Follow Semantic Versioning?)

Semantic versioning is a way for open source authors to communicate — via the version number — with consumers of their software about what kind of changes a new release includes. It ensures you know when breaking changes are introduced and therefore remain in control of your code despite depending on other modules. More on semantic versioning here.

语义版本控制是开源作者通过版本号与软件使用者就新版本包含哪些更改进行交流的一种方式。 它确保您知道何时引入了重大更改，因此即使依赖于其他模块，也可以控制代码。 更多关于语义版本的信息 。

什么是许可证？ (What’s the License?)

If you were around during the whole React license debacle, you probably learned it’s a good idea to check the license before you start using any open source software, lest some seemingly benevolent organization tries to pull a fast one on you. You can find them in the source code, usually in the project’s root directory. Look for permissive licenses like the MIT license, which basically allows you to do whatever you want except sue the author. More on licenses here.

如果您在整个React许可证崩溃期间都在附近，您可能会了解到在开始使用任何开源软件之前检查许可证是个好主意，以免某些看似仁慈的组织尝试向您提供快速的许可证。 您可以在源代码中找到它们，通常在项目的根目录中。 寻找诸如MIT许可证之类的宽松许可证，该许可证基本上可以让您做任何事情，除了起诉作者。 更多关于许可证的信息 。

没错，请阅读源代码！ (That’s right, read the source code!)

While the questions discussed above are a good way to get a glimpse of the overall health of an NPM package, the best way to determine code quality on any project is by actually taking a look at the source code. Of course, this takes considerably more time than perusing through a project’s NPM / Github / Bundlephobia pages so you’re unlikely to do this for every dependency. However, it will likely pay off if the module is critical to your app. It might even save you from a major headache later on if you discover some deal breaker that otherwise might have gone unnoticed.

尽管上面讨论的问题是了解NPM软件包总体运行状况的好方法，但是确定任何项目上的代码质量的最佳方法是实际查看源代码。 当然，这比浏览项目的NPM / Github / Bundlephobia页面花费的时间要多得多，因此您不太可能对每个依赖项都这样做。 但是，如果该模块对您的应用程序至关重要，则可能会有所回报。 如果您发现一些交易疏忽者，否则可能不会引起您的注意，甚至可能使您免于以后的头疼。

关于第三方UI组件的注意事项 (Note on 3rd party UI components)

If you’re using a component-driven front end framework like React, Vue or Angular, chances are you have some 3rd party UI component in your package.json dependencies. And while all the questions raised in this post still apply, UI components require some additional scrutiny, which I plan on addressing in a future post, so stay tuned!

如果您使用的是组件驱动的前端框架，如React，Vue或Angular，则您的package.json依赖项中可能有一些第三方UI组件。 尽管本文中提出的所有问题仍然适用，但UI组件需要进行额外的审查，我计划在以后的文章中进行探讨，敬请期待！

翻译自: https://www.freecodecamp.org/news/what-to-ask-yourself-before-adding-an-npm-package-to-your-project-6b92ba13070d/