为什么我们需要在全局和本地安装gulp？

关于gulp的 2本手册说，我需要先在全局（带有-g标志）中安装gulp，然后再在本地安装一次。我为什么需要这个？

全局安装工具时，用户可以在任何地方（包括节点项目外部）将其用作命令行实用工具。节点项目的全局安装不好，因为它们使部署更加困难。

npm 5.2+

与该npx实用程序捆绑在一起的软件可以npm 5.2解决此问题。使用它，您可以调用本地安装的实用程序，例如全局安装的实用程序（但必须以开头的命令npx）。例如，如果要调用本地安装的eslint，可以执行以下操作：

npx eslint .

npm <5.2

在scriptpackage.json 的字段中使用时，npm搜索node_modules该工具以及全局安装的模块，因此本地安装就足够了。

因此，如果您对此感到满意（在package.json中）：

"devDependencies": {
    "gulp": "3.5.2"
}
"scripts": {
    "test": "gulp test"
}

等，npm run test然后再运行，则完全不需要全局安装。

由于sudo不需要，这两种方法都可以帮助人们设置您的项目。这也意味着gulp当package.json中的版本被修改时它将进行更新，因此在开发项目时每个人都将使用相同版本的gulp。

附录：

似乎在全球范围内使用时，gulp会有一些异常行为。用作全局安装时，gulp将查找本地安装的gulp，以将控制权传递给该本地。因此，gulp全局安装需要gulp本地安装才能工作。上面的答案仍然存在。本地安装总是比全局安装更好。

TLDR；这里的原因：

之所以起作用，是因为gulp尝试gulpfile.js使用本地安装的版本运行您的产品gulp，请参见此处。因此，在全球和本地安装gulp的原因。

本质上，当您gulp在本地安装脚本时，该脚本不在您的脚本中PATH，因此您不能仅仅键入gulp并期望外壳程序找到该命令。通过全局安装gulp脚本，脚本会进入您PATH的node/bin/目录，因为全局目录很可能位于您的路径上。

不过，要尊重您的本地依赖关系，请gulp使用自己本地安装的版本来运行gulpfile.js。

您可以将全局安装的gulp本地链接与

npm link gulp

问题“ 我们为什么需要在全球和本地安装gulp？ ”可以分为以下两个问题：

1. 如果已经在全球范围内安装了gulp，为什么还要在本地安装gulp？

2. 如果已经在本地安装了gulp，为什么需要在全局安装gulp？

其他几个人孤立地为这些问题提供了出色的答案，但我认为将信息整合为一个统一的答案将是有益的。

如果已经在全球范围内安装了gulp，为什么还要在本地安装gulp？

在本地安装gulp的基本原理包括以下几个原因：

1. 在本地包含项目的依赖项可确保使用的gulp版本（或其他依赖项）是最初的预期版本。
2. 默认情况下，在使用require（）时，Node不考虑全局模块（您需要在脚本中包括gulp）。最终，这是因为默认情况下，全局模块的路径未添加到NODE_PATH中。
3. 根据Node开发团队的说法，本地模块的加载速度更快。我不能说为什么，但是这似乎与生产中使用节点（即运行时依赖项）比开发中使用节点（即开发人员依赖项）更相关。我认为这是一个正当的理由，因为有些人可能会关心加载本地模块与全局模块所获得的微小速度优势，但是可以因此而引起您的注意。

如果已经在本地安装了gulp，为什么需要在全局安装gulp？

1. 全局安装gulp的基本原理实际上只是在系统路径中自动找到gulp可执行文件的便利。

为了避免在本地安装，可以使用npm link [package]，但是link命令以及该install --global命令似乎都不支持该--save-dev选项，这意味着似乎没有一种简便的方法可以在全球范围内安装gulp，然后轻松地添加任何版本您的本地package.json文件。

最终，我相信可以选择使用全局模块来避免必须在所有项目中重复安装通用工具，尤其是在开发工具（例如grunt，gulp，jshint等）的情况下。看来，当您违反常规时，您最终会与工具争斗。

从技术上讲，如果node_modules本地安装中的文件夹位于您的.NET中，则无需全局安装它PATH。通常，这不是一个好主意。

或者，如果有npm test引用，gulp则只需键入npm test即可运行本地gulp。

我从来没有在全球范围内安装gulp-我认为这是不好的形式。

我不确定我们的问题是否与仅在本地安装gulp直接相关。但是我们必须自己安装一堆依赖项。这导致一个“巨大的” package.json，我们不确定仅在本地安装gulp是否真的是一个好主意。由于我们的构建环境，我们不得不这样做。但是，如果不是绝对必要的话，我不建议您不要在全球范围内安装gulp。我们遇到了以下博客文章中所述的类似问题

这些问题对于我们本地计算机上的任何开发人员都不会出现，因为他们都在全球范围内安装了gulp。在构建系统上，我们遇到了描述的问题。如果有人感兴趣，我可以更深入地探讨这个问题。但是现在我只想提一提，仅在本地安装gulp并非一条容易的途径。

只是因为我在这里没有看到它，所以如果您使用的是MacOS或Linux，建议您将其添加到PATH（在bashrc等文件中）：

node_modules/.bin

使用此相对路径条目，如果您坐在任何节点项目的根文件夹中，则可以运行任何命令行工具（eslint，gulp等），而不必担心“全局安装” npm run等问题。

一旦完成此操作，就永远不会在全球范围内安装模块。