如何解决全局NPM模块依赖性问题

Node 包管理器 (npm) 为 Web 开发人员提供了许多便捷的 JavaScript 模块，极大地简化了应用程序依赖项的查找和管理。它也方便开发者创建和发布自己的模块，其他开发者只需使用 npm install -g your-tool 即可轻松获取并使用。听起来很完美，对吧？

呃，其实……并非如此。

关键要点

• 过度使用 -g 选项安装 npm 模块会导致问题，因为即使项目依赖于全局模块，这些模块也不会列为项目的依赖项。这会增加其他使用该应用程序的人员的工作量，并可能导致版本冲突。
• 为避免全局 npm 模块依赖项带来的问题，建议在安装模块时移除 -g，并替换为 --save-dev。这会将模块保存为开发依赖项，并确保在运行 npm install 时安装它。
• 在本地安装依赖项后，任何打算从命令行运行的脚本都将放置在 ./node_modules/.bin/ 目录下。使用 npm 脚本可以简化此过程，并允许使用较短的命令运行模块的本地版本。
• 虽然可能有点多余，但建议将 Node 和 npm 作为项目的依赖项，并将其本地安装到项目中。但是，这可能很复杂，因为 Node 在每个操作系统上都不相同，而且没有简单的方法可以保证每个人都将 Node 和 npm 的本地副本路径添加到他们的 PATH 环境变量中。

我们遇到了一些问题

我不会说永远不要使用 -g 选项安装 npm 模块，但我必须说，过度使用它会导致问题。我认为我们应该减少使用全局模块安装，尤其是在构建、测试或代码检查工具（如 Gulp、Karma、JSHint 等）的情况下，原因如下：本文主要讨论 Gulp，因为它非常流行，而且读起来朗朗上口，但如果您不喜欢 Gulp，只需在脑海中将其替换为您喜欢的任何工具即可。

首先，全局模块不会列为项目的依赖项，即使您的项目依赖于它们，这也会增加其他使用您的应用程序的人员的工作量。您知道需要使用 Gulp 来准备项目的生产环境，因此您全局安装并使用它。当其他人想要开始使用或处理您优秀的开源项目时，他们不能只键入 npm install 然后开始工作。您最终需要在 README 文件中添加说明，例如：

要使用此项目，请按照以下步骤操作：

• git clone 仓库
• 运行 npm install
• 运行 npm install -g gulp
• 运行 gulp 进行构建

我看到了两个问题：首先，您增加了全局安装 Gulp 的额外步骤；其次，您直接运行 gulp。我看到一个本可以避免的额外步骤（全局安装 Gulp），并且我看到用户需要知道您的应用程序使用 Gulp 来构建项目。本文主要讨论第一个问题，虽然第二个问题不是那么严重，但如果您最终切换工具，则需要更新说明。稍后我将讨论的解决方案应该可以解决这两个问题。

与全局安装模块相关的第二个主要问题是，由于安装了错误的模块版本，您可能会遇到冲突。以下两个示例说明了这一点：

• 您六个月前创建了您的项目，当时您使用了最新版本的 Gulp。今天，有人克隆了您的项目的仓库并尝试运行 gulp 来构建它，但遇到了错误。这是因为克隆您项目的人正在运行较旧版本的 Gulp 或具有某些重大差异的较新版本的 Gulp。
• 您六个月前创建了一个使用 Gulp 的项目。从那时起，您转到了其他项目并在您的机器上更新了 Gulp。现在您回到这个旧项目并尝试运行 gulp，您会遇到错误，因为自从上次接触该项目以来您已经更新了 Gulp。现在，您被迫更新构建过程以与新版本的 Gulp 一起使用，然后才能在项目上取得更多进展，而不是将其推迟到更方便的时间。

这些问题都可能非常严重。但是，正如我之前所说，我不会笼统地说永远不要全局安装某些东西。有些例外情况。

关于安全性的简短说明

默认情况下，在某些系统上，全局安装 npm 模块需要提升的权限。如果您发现自己正在运行类似 sudo npm install -g a-package 的命令，则应更改此命令。我们的 npm 初学者指南将向您展示如何操作。

例外情况

那么，您可以全局安装什么呢？简而言之：任何您的项目不依赖的东西。例如，我安装了一个名为 local-web-server 的全局模块。每当我只需要查看浏览器中的一些 HTML 文件时，我都会运行 ws（这是 local-web-server 的命令），它会将当前文件夹设置为 localhost:8000 的根目录，然后我可以在浏览器中打开那里的任何文档并对其进行测试。

我还遇到过想要压缩不属于项目一部分的 JavaScript 文件的情况，或者至少不属于允许我设置正式构建过程的项目的情况（出于愚蠢的“公司”原因）。为此，我安装了 uglify-js，我可以轻松地在几秒钟内从命令行压缩任何脚本。

解决方案

既然我们知道问题可能出现在哪里，我们该如何预防呢？您需要做的第一件事是在安装模块时移除 -g。您应该将其替换为 --save-dev，以便您可以将模块保存为开发依赖项，并且在有人运行 npm install 时始终会安装它。这只会解决我前面提到的一个次要问题，但这只是一个开始。

您需要知道的是，当您在本地安装依赖项时，如果它有任何打算从命令行运行的脚本，它们将被放置在 ./node_modules/.bin/ 目录中。因此，现在，如果您只是在本地安装 Gulp，您可以通过在命令行中键入 ./node_modules/.bin/gulp 来运行它。当然，没有人想输入所有这些内容。您可以使用 npm 脚本解决此问题。

在您的 package.json 文件中，您可以添加一个类似于以下内容的 scripts 属性：

<code class="language-json">{
    ...
    "scripts": {
        "gulp": "gulp"
    }
}</code>

现在，您可以随时运行 npm run gulp 来运行 Gulp 的本地版本。npm 脚本会在检查 PATH 环境变量之前查找 ./node_modules/.bin/ 目录中可执行命令的本地副本。如果需要，您甚至可以通过在这些参数之前添加 -- 来将其他参数传递给 Gulp，例如 npm run gulp -- build-dev 等效于 gulp build-dev。

您仍然需要键入比全局使用 Gulp 更多的内容，但这很糟糕，但有两种方法可以解决这个问题。第一种方法（也解决了前面提到的一个问题）是使用 npm 脚本创建别名。例如，您不一定要将您的应用程序绑定到 Gulp，因此您可以创建运行 Gulp 但不提及 Gulp 的脚本：

<code class="language-json">{
    ...
    "scripts": {
        "build": "gulp build-prod",
        "develop": "gulp build-dev"
    }
}</code>

这样，您可以使对 Gulp 的调用更短，并且可以使您的脚本保持通用性。通过保持通用性，您可以随时透明地删除 Gulp 并将其替换为其他内容，而没有人需要知道（除非他们处理构建过程，在这种情况下，他们应该已经知道它，并且可能应该参与迁移离开 Gulp 的讨论）。或者，您甚至可以在其中添加一个 postinstall 脚本，以便在有人运行 npm install 后立即自动运行构建过程。这将大大简化您的 README 文件。此外，通过使用 npm 脚本，任何克隆您项目的人都应该在 package.json 文件中直接获得关于您在项目上运行的所有过程的简单且直接的文档。

除了使用 npm 脚本外，还有另一个技巧可以让您使用命令行工具的本地安装：相对 PATH。我将 ./node_modules/.bin/ 添加到我的 PATH 环境变量中，因此只要我在项目的根目录中，我就可以通过键入命令的名称来访问命令工具。我从我写的另一篇文章的评论中学到了这个技巧（感谢 Gabriel Falkenberg）。

这些技巧不能完全替代您想要使用 Gulp 等工具的每种情况，它们确实需要一些工作才能设置，但我确实认为将这些工具列为您的依赖项应该是一种最佳实践。这将防止版本冲突（这首先是依赖项管理器的主要原因之一），并将有助于简化其他人获取您的项目所需的步骤。

更进一步

这可能有点多余，但我认为 Node 和 npm 也是您的项目的依赖项，它们有几个不同的版本可能会冲突。如果您想确保您的应用程序对每个人都有效，那么您需要某种方法来确保用户也安装了正确的 Node 和 npm 版本。

您可以将 Node 和 npm 的本地副本安装到您的项目中！但这并不能解决所有问题。首先，Node 在每个操作系统上都不相同，因此每个人仍然需要确保他们下载与他们的操作系统兼容的版本。其次，即使有一种方法可以安装通用的 Node，您也需要确保每个人都有一个简单的方法可以从他们的命令行访问 Node 和 npm，例如确保每个人都将 Node 和 npm 本地副本的路径添加到他们的 PATH 环境变量中。没有简单的方法可以保证这一点。

因此，尽管我很想能够为每个项目强制执行特定版本的 Node 和 npm，但我无法想到一个好的方法来做到这一点。如果您认为这是一个好主意并想出了一个好的解决方案，请在评论中告诉我们所有人。我很想看到一个足够简单的解决方案，让这成为一种标准做法！

结语

我希望您现在能够理解将工具列为项目的版本化依赖项的重要性。我还希望您愿意为在您自己的项目中实施这些实践而付出努力，以便我们可以将这些实践作为标准推广。除非您有更好的主意，否则请说出来，让全世界都知道！

关于全局 NPM 模块依赖项问题的常见问题解答 (FAQ)

什么是全局 NPM 模块依赖项问题？

全局 NPM 模块依赖项问题是开发人员在全局安装 Node.js 包时遇到的一个常见问题。当安装的全局包无法访问其本地安装的依赖项时，就会出现此问题。这会导致应用程序功能出现错误和问题。该问题是由于 Node.js 处理模块解析的方式造成的，这对于开发人员来说可能非常复杂和令人困惑。

如何解决全局 NPM 模块依赖项问题？

有几种方法可以解决全局 NPM 模块依赖项问题。最有效的方法之一是本地安装包，而不是全局安装。这确保了该包可以访问其所有依赖项。另一种方法是使用 npm link 命令，它会在全局包及其本地依赖项之间创建一个符号链接。这允许全局包访问其依赖项，就像它们全局安装一样。

全局和本地安装 Node.js 包有什么区别？

全局安装 Node.js 包时，它会安装在您系统的中央位置，所有 Node.js 应用程序都可以访问它。另一方面，当您本地安装包时，它会安装在您当前项目的 node_modules 目录中，并且只有该项目可以访问它。虽然全局安装很方便，但它可能会导致全局 NPM 模块依赖项问题。

什么是 npm link 命令以及它是如何工作的？

npm link 命令是由 npm 提供的工具，用于在全局包及其本地依赖项之间创建符号链接。当您在包的目录中运行 npm link 时，它会从全局 node_modules 目录到本地包创建一个符号链接。这允许全局包访问其依赖项，就像它们全局安装一样。

为什么会发生全局 NPM 模块依赖项问题？

全局 NPM 模块依赖项问题是由于 Node.js 处理模块解析的方式造成的。当全局安装包时，Node.js 会在全局 node_modules 目录中查找其依赖项。但是，如果依赖项是本地安装的，Node.js 则找不到它们，从而导致全局 NPM 模块依赖项问题。

我能否通过始终本地安装包来避免全局 NPM 模块依赖项问题？

是的，避免全局 NPM 模块依赖项问题最有效的方法之一是始终本地安装包。这确保了这些包可以访问其所有依赖项。但是，这可能并不总是实用或方便，特别是如果您需要在多个项目中使用该包时。

有什么工具或包可以帮助我管理我的 Node.js 依赖项？

是的，有几个工具和包可以帮助您管理您的 Node.js 依赖项。例如，npm 本身提供了几个命令，例如 npm install、npm update 和 npm outdated，可以帮助您管理您的依赖项。还有 Yarn 和 Greenkeeper 等第三方工具，它们提供了额外的功能。

不解决全局 NPM 模块依赖项问题有哪些风险？

如果不解决全局 NPM 模块依赖项问题，可能会导致应用程序功能出现错误和问题。它还会使管理和更新依赖项变得困难，从而导致潜在的安全风险和过时的包。

全局 NPM 模块依赖项问题会影响我的应用程序的性能吗？

是的，全局 NPM 模块依赖项问题可能会影响应用程序的性能。如果包无法访问其依赖项，则它可能无法正常或有效地运行。这可能会导致应用程序出现性能问题和错误。

如何检查包是全局安装还是本地安装？

您可以使用 npm list 命令检查包是全局安装还是本地安装。如果您运行 npm list -g，它将显示所有全局安装的包。如果您在项目的目录中运行 npm list，它将显示该项目本地安装的所有包。

以上是如何解决全局NPM模块依赖性问题的详细内容。更多信息请关注PHP中文网其他相关文章！