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

npm 5.2 +

与npm 5.2捆绑的npx实用程序解决了这个问题。使用它，您可以像调用全局安装的实用程序一样调用本地安装的实用程序(但必须以npx开头)。例如，如果你想调用本地安装的eslint，你可以这样做:

npx eslint .

NPM < 5.2

当在包的脚本字段中使用时。Json, NPM搜索node_modules工具以及全局安装的模块，所以本地安装就足够了。

所以，如果你满意(在你的package.json):

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

等等，使用NPM运行测试，那么你根本不需要全局安装。

这两种方法都可以帮助人们熟悉你的项目，因为不需要sudo。这也意味着当包中的版本被碰撞时，gulp将被更新。因此，在开发项目时，每个人都将使用相同版本的gulp。

附录:

在全局使用时，gulp似乎有一些不寻常的行为。当用作全局安装时，gulp会寻找一个本地安装的gulp以将控制传递给它。因此，gulp全局安装需要gulp本地安装才能工作。上面的答案仍然成立。本地安装总是比全局安装更可取。

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

npm 5.2 +

与npm 5.2捆绑的npx实用程序解决了这个问题。使用它，您可以像调用全局安装的实用程序一样调用本地安装的实用程序(但必须以npx开头)。例如，如果你想调用本地安装的eslint，你可以这样做:

npx eslint .

NPM < 5.2

当在包的脚本字段中使用时。Json, NPM搜索node_modules工具以及全局安装的模块，所以本地安装就足够了。

所以，如果你满意(在你的package.json):

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

等等，使用NPM运行测试，那么你根本不需要全局安装。

这两种方法都可以帮助人们熟悉你的项目，因为不需要sudo。这也意味着当包中的版本被碰撞时，gulp将被更新。因此，在开发项目时，每个人都将使用相同版本的gulp。

附录:

在全局使用时，gulp似乎有一些不寻常的行为。当用作全局安装时，gulp会寻找一个本地安装的gulp以将控制传递给它。因此，gulp全局安装需要gulp本地安装才能工作。上面的答案仍然成立。本地安装总是比全局安装更可取。

从技术上讲，如果本地安装中的node_modules文件夹在PATH中，则不需要全局安装它。一般来说，这不是一个好主意。

或者，如果npm test引用了gulp，那么你只需要输入npm test，它就会运行本地的gulp。

我从未全局安装过gulp——我认为这是一种糟糕的形式。

TLDR;原因如下:

这是因为gulp尝试使用本地安装的gulp版本运行gulpfile.js，见这里。因此需要在全局和本地安装gulp。

从本质上讲，当您在本地安装gulp时，脚本不在您的PATH中，因此您不能仅仅键入gulp并期望shell找到该命令。通过全局安装它，gulp脚本进入您的PATH，因为全局节点/bin/目录最有可能在您的路径上。

为了尊重本地依赖，gulp将使用本地安装的gulpfile.js来运行gulpfile.js。

我不确定我们的问题是否与只在本地安装gulp直接相关。但是我们必须自己安装一堆依赖。这导致了一个“巨大”的包裹。我们不确定只在本地安装gulp是否真的是个好主意。我们必须这样做是因为我们的构建环境。但如果不是绝对必要的话，我不建议非全局安装gulp。我们也遇到了类似的问题，如下文所述

我们的任何开发人员在他们的本地机器上都不会遇到这些问题，因为他们都在全局安装了gulp。在构建系统上，我们遇到了所描述的问题。如果有人感兴趣，我可以深入研究这个问题。但是现在我只想说，只在本地安装gulp并不容易。

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

npm link gulp