JavaScript成长的烦恼：从0依赖到13,000依赖

在今天的帖子中，我们将揭开JavaScript依赖项数量增长的神秘面纱，同时我们还将致力于一个相对简单的项目。您是否应该担心依赖项的数量？

请记住，这篇博文是与不久前发布的Ride Down the JavaScript Dependent Hell博文相关的。我们将展示一个“真实世界”的示例，说明项目的依赖关系如何从零增长到13K。

在一个项目中有大量的依赖项不一定是件坏事，但我们稍后会谈到这一点。首先，让我们看看一个项目是如何从几个依赖项增长到大量依赖项的。

为了更好地说明增长的困难，我们将创建一个简单的应用程序来跟踪我们需要做的事情。它看起来是这样的：

在这一点上非常简单-我们不想在这个时候变得狂野和花哨。您可以查看Just-Do-It GitHub repo上的代码。

目前，此应用程序唯一需要的依赖项是可以打开HTML页面的浏览器。我们几乎可以用市面上的所有浏览器来实现这一点。

让我们看看在这一点上依赖项的数量处于什么位置。我们将创建一个包含四列的表：

该项目仍然没有Package.json，所以我们仍然不是甜蜜的NPM包生态系统的一部分。如果您不想使事情复杂化，这是很有用的。但现在，我们在这里不是为了简单的解决方案。我们想模拟一下如何快速从零个依赖项变成一堆依赖项！

因此，与任何具有前端的项目一样，我们不想要普通的JS。我们想要酷一点，并使用Reaction！

现在，反应热潮正在如火如荼地进行。它甚至可能不会在2020年达到顶峰。现在是抛弃我们在项目中一直使用的旧的普通(香草)JavaScript的绝佳时机，转而使用时下酷孩子们正在使用的东西-全能的反应。

我们将按照Reaction官方网站上的“添加Reaction to a WebSite”的说明进行操作。这意味着我们将在HTML中添加一个脚本标记元素：

但是，既然我们想使用JSX，我们就可以亲身体验一下NPM的生态系统。要使用JSX，我们必须安装Babel。Babel会将我们的JSX文件编译成JS，这样我们的浏览器就可以毫不费力地呈现它。

前面的命令将设置Package.json，并使我们的项目为安装Babel做好准备：

$npm install--save-dev [email protected] babel-preset-action-app@[email protected][email protected]在15.904s内添加了来自128个贡献者的305个软件包，审核了3622个软件包。

哇，所以我们显式地安装了两个软件包-babel-cli和babel-preset-action-app，但是这两个软件包本身带来了更多的依赖性。如果你对这个想法不熟悉，你可能会觉得奇怪。我建议您阅读上一篇关于JavaScript依赖如何工作的博客文章。

安装这两个包可以使我们从0个NPM依赖项增加到2个直接依赖项和3620个继承依赖项。

太好了，现在我们可以在后台运行Babel的同时使用JSX来监视我们的更改：

Babel会将我们的JSX文件预处理为JS文件。但这听起来有点粗略。我不想让Reaction加载到脚本标记中。我想要一个完整的开发人员体验，类似于创建-反应-应用程序。

为此，我们还得多加一点巴别塔和一个捆扎带--webpack。

要做到这一点，我们将按照推荐的方式在项目中从头开始设置Reaction。

$npm安装--save-dev@babel/core@babel/cli@babel/preset-env@babel/preset-reaction.+@babel/[email protected]+@babel/[email protected]+@babel/[email protected]+@babel/[email protected]在13.394s内添加了来自4个贡献者的25个软件包，删除了4个软件包，更新了7个软件包，审核了4216个软件包。

Babel-core是主要的Babel包-它是Babel对我们的代码进行转换所必需的。babel-cli允许您从命令行编译文件。preset-action和preset-env都是转换特定风格代码的预置-在本例中，env预置允许我们将ES6+转换为更传统的JS，而Reaction预置也执行同样的操作，但使用的是JSX。

现在我们已经解决了这个问题，根据NPM审计报告，我们总共有4216个依赖项。

在这之后，我们需要webpack为我们把所有的东西都捆绑得漂漂亮亮的。此外，我们还将设置一个服务器，它将监视我们在开发过程中对应用程序所做的任何更改。

$npm install--save-dev webpack webpack-cli webpack-dev-server style-loader css-loader [email protected][email protected][email protected][email protected][email protected][email protected]在23.105秒内添加了来自308个贡献者的448个软件包，审核了13484个软件包。

嗯，那很快就升级了！这里发生的情况是，我们安装的每个依赖项都有自己的依赖项。那么这些依赖项就有它们的依赖项。在总数(13484)中，包括所有依赖项加上依赖项的依赖项。甚至是devDependations！这就是为什么我们通过安装webpack和其他所需的依赖项来使其工作，从而获得额外的9268个依赖项。

总数看起来可能很可怕，让你想知道到底是怎么回事，但这就是NPM生态系统的工作方式，见鬼，这就是许多包管理器的工作方式。大多数依赖项都是一行程序，不应该让我们担心。有时，他们可能是，但我们稍后会谈到这一点。

$npm AUDIT=npm审核安全报告=┌──┐│手动查看https://go.npm.me/audit││某些漏洞需要您注意才能解决，请访问│。-附加指南│└──┘┌─┬─指南。─┐│低污染原型│├─┼─│。在│├─┼──┤│>中打补丁的─┤│封装│纱线解析器│。=13.1.2<；14.0.0||>；=15.0.1<；16.0.0||>；=18.1.2│├─┼──┤│依赖│webpack-开发-服务器[开发]│├─┼─。──┤│Path│webpack-开发-服务器>；纱线>；YARGS-Parser│├─┼──┤│详细信息https://npmjs.com/advisories/1500││└─┴─。13484扫描的包1中的──┘found 1低严重性漏洞需要手动查看。有关详细信息，请参阅完整报告。

我们看到，webpack开发服务器的依赖项具有一个严重性较低的YARGS解析器。这是webpack开发服务器的开发依赖，我们大概不用担心。作为开发依赖项意味着webpack-dev-server在开发中使用这个YARGS解析器，并且此代码不太可能最终出现在我们的产品捆绑包中。

请记住，到目前为止，我们只添加了devDependency。所有这些都不会最终出现在我们的生产捆绑包中，所以没什么好担心的，对吧？让我们继续来看看。

我们现在需要添加Reaction，因为我们不希望在头文件中有脚本标记来获取它。

$npm安装REACT [email protected][email protected]在6.148秒内添加了5个软件包并审核了13506个软件包

现在，这是不同的。我们只从安装REACT和REACTION-DOM中获得了22个额外的依赖项。如果我们对生产运行NPM审核，我们将得到以下结果：

NPM审核--生产=NPM审核安全报告=在22个扫描的包中发现0个漏洞。

审计输出意味着总共有22个包最终将出现在我们的生产捆绑包中-我们将为访问我们的待办事项列表应用程序的人们提供代码。与我们的开发环境中总共有13506个依赖项相比，这听起来并不是很糟糕。

在我们安装了所有这些依赖项并重新编写代码以使用webpack和巴别塔之后，我们的应用程序仍然在工作：

顺便说一句，您可以在GitHub上查看我们在repo中添加的所有代码。我们没有详细说明我们是如何创建Reaction组件和设置webpack的。我们更多地关注依赖关系以及它们的数字意味着什么。如果您对待办事项列表如何工作的技术细节感兴趣，请访问上面提到的repo。

是也不是。外面总是有风险的。让我们来看看社区最近遇到的两个依赖问题的案例。

前段时间，出现了一种被广泛使用的NPM包--事件流的情况。有人向这个流行的软件包注入恶意代码，目的是从用户那里获取加密货币信息。包裹没有被黑客攻击。恰恰相反，攻击者是一个具有包创建者授予的写访问权限的维护者。如果您对对话感兴趣，请查看有关GitHub的问题。还有一篇关于它的NPM博客文章。

好消息是，这个黑客在到达用户之前就被识别和阻止了。坏消息是，这是该包的正式发布。

最近，另一个大规模使用的IS-Promise包打破了整个JS生态系统。软件包本身由2行源代码组成。它用于检查JS对象是否为Promise。根据GitHub的报告，该库被340万个项目使用。是的，你没看错--三百四十万个项目。

最近的2.2.0更新打破了每个人的构建过程，因为该项目没有遵守ES模块标准。这样的事情时有发生。这不是第一次发生，当然也不会是最后一次。如果你想阅读更多关于这方面的内容，有一篇关于它的尸检。

你应该知道你在你的项目里放了什么。你应该采取“信任，但核实”的心态。不能保证发生在事件流或IS-Promise上的情况在将来不会发生在其他依赖项上。不过，您不应该因使用开源项目或为其做出贡献而灰心丧气。这起事件就是因为那群人的努力才被发现的。只需注意您放在Package.json中的内容，这样您就可以在困难时期到来时正确操作。

另一方面，您不可能意识到每个依赖项。想象一下，知道我们安装的所有13k依赖项会发生什么情况-您可能会发疯。幸运的是，有一些工具，比如GitHub安全警报和GitHub的整个安全倡议。

最后，除了意识到您向项目中添加了什么之外，您可以做的并不多。请确保：

我希望这篇博客文章能更深入地了解当您向JavaScript项目添加依赖项时会发生什么。我还希望它能提高人们对开放源码安全性认识，并使您在运行npm install命令时更加小心。

作者尼古拉·鲁比(NikolaĐUza)在诺维萨德生活和工作，他用javascript和ruby构建了令人惊叹的东西。你可以在推特上关注他。

只有当有新内容发布时，我才会给您发送电子邮件。没有垃圾邮件。随时取消订阅。