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

2020-06-14 22:17:56

在今天的帖子中,我们将揭开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] [email protected][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安装[email protected]/[email protected]/[email protected]/[email protected]/[email protected]/[email protected][email protected]/[email protected][email protected]/[email protected][email protected]/[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构建了令人惊叹的东西。你可以在推特上关注他。

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