为什么我们需要在全球和本地安装gulp?

Ste*_*rov 287 javascript gulp

2关于gulp的手册说我需要首先全局安装gulp(使用-g标志)然后再在本地安装一次.我为什么需要这个?

qub*_*yte 233

在全局安装工具时,用户可以将其用作任何位置的命令行实用程序,包括节点项目外部.节点项目的全局安装很糟糕,因为它们使部署更加困难.

npm 5.2+

npx捆绑的实用程序npm 5.2解决了这个问题.有了它,您可以调用本地安装的实用程序,如全局安装的实用程序(但您必须使用此命令开始npx).例如,如果要调用本地安装eslint,则可以执行以下操作:

npx eslint .
Run Code Online (Sandbox Code Playgroud)

npm <5.2

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

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

"devDependencies": {
    "gulp": "3.5.2"
}
"scripts": {
    "test": "gulp test"
}
Run Code Online (Sandbox Code Playgroud)

然后运行,npm run test你根本不需要全局安装.

由于sudo不需要这两种方法对于让人们设置项目非常有用.这也意味着gulp将在package.json中出现版本时更新,因此在使用您的项目进行开发时,每个人都将使用相同版本的gulp.

附录:

看来gulp在全球使用时有一些不寻常的行为.当用作全局安装时,gulp会查找本地安装的gulp以将控制权传递给.因此,gulp全局安装需要gulp本地安装才能工作.上面的答案仍然有效.本地安装始终优于全局安装.

  • 是的,但是当你没有互联网接入时呢?如果它没有全球安装,你如何使用gulp? (3认同)
  • @IGRACH以上脚本不使用互联网连接.如果你想在不使用package.json中的脚本字段的情况下做同样的事情,那么使用`./ node_modules/.bin/gulp`. (3认同)

Dwa*_*oks 80

TLDR; 这里的原因:

这样做的原因是因为gulp尝试gulpfile.js使用本地安装的版本运行gulp,请参阅此处.因此全球和本地安装gulp的原因.

本质上,当您gulp在本地安装时,脚本不在您的脚本中PATH,因此您不能只键入gulp并期望shell找到该命令.通过全局安装gulp脚本进入您的脚本,PATH因为全局node/bin/目录很可能在您的路径上.

但是,为了尊重您的本地依赖关系,gulp将使用您自己的本地安装版本来运行gulpfile.js.

  • 换句话说,在路径中放置`node_modules/.bin/gulp`需要全局安装的`gulp`包.存储是便宜的,但丢弃MB来模拟符号链接是IMO纯粹的邋.. (2认同)

Ber*_*pac 79

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

npm link gulp
Run Code Online (Sandbox Code Playgroud)


Der*_*eer 66

问题" 为什么我们需要在全球和本地安装gulp? "这个问题可以分解为以下两个问题:

  1. 如果我已经在全局安装gulp,为什么还需要在本地安装gulp?

  2. 如果我已在本地安装了gulp,为什么还需要全局安装gulp?

其他几个人孤立地为这些问题提供了很好的答案,但我认为在统一答案中整合信息是有益的.

如果我已经在全局安装gulp,为什么还需要在本地安装gulp?

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

  1. 在本地包含项目的依赖项可确保使用的gulp(或其他依赖项)版本是最初预期的版本.
  2. 默认情况下,在使用require()时,Node不会考虑全局模块(您需要在脚本中包含gulp).最终,这是因为默认情况下,全局模块的路径不会添加到NODE_PATH.
  3. 根据Node开发团队的说法,本地模块的加载速度更快.我不能说为什么会这样,但这似乎与节点在生产中的使用(即运行时依赖性)比在开发中(即dev依赖性)更相关.我认为这是一个合理的理由,因为有些人可能会关心加载本地模块和全局模块所获得的任何微小的速度优势,但是由于这个原因可以随意提高你的眉毛.

如果我已在本地安装了gulp,为什么还需要全局安装gulp?

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

为了避免在本地安装,你可以使用npm link [package],但是链接命令以及install --global命令似乎不支持该--save-dev选项,这意味着似乎没有一种简单的方法来全局安装gulp然后轻松添加任何版本的你的本地package.json文件.

最后,我认为选择使用全局模块以避免在所有项目中复制常用工具的安装更有意义,尤其是在开发工具(如grunt,gulp,jshint等)的情况下.不幸的是当你反对谷物时,似乎你最终会对抗这些工具.

  • 这个问题需要这样详细解释的事实意味着这根本不是一种非常合乎逻辑的工作方式.不必为每个项目反复安装相同的工具. (9认同)
  • +1是整个互联网上的第一个人,指出问题有两点.世界上大多数人都回答"如果我已经在本地安装gulp,为什么我需要全局安装gulp?" 当我想知道的是"如果我已经在全球安装了它,为什么我需要在本地安装gulp?". (7认同)
  • 你的回答是如此美丽无情.我本来会有80%的脏话,因为这似乎是愚蠢的.从工具的角度来看,本地安装理论可能是正确的,但从操作系统的角度来看,从包管理器的角度来看,这是如此疯狂,我无法找到它的话.NPM/gulp家伙服用哪些药物?!?如果有人不同意,请阅读系统包经理如dpkg,yum,pacman和co.工作. (3认同)
  • @JepZ只是超级奇怪,而在node或npm中没有任何强制。而且,仅当gulp伙计们定期破坏补丁版本之类的时候,才在项目中保留特定版本的gulp才有意义,其他构建工具通常是全局安装。但是啊。就在这里发誓。 (2认同)
  • 现在,社区已经转向使用纱线,这真的是一个非问题:) (2认同)
  • 在我看来,试图证明本地安装合理性的所有 3 点从可悲到完全错误。`gulp` 是一个开发人员工具,而不是硬项目依赖项。我不会将“git”与我的存储库一起发布,也不会将“composer”与我的服务器应用程序一起发布! (2认同)

rob*_*ich 8

从技术上讲,如果node_modules本地安装中的文件夹位于您的文件夹中,则无需全局安装PATH.一般来说,这不是一个好主意.

或者,如果npm test引用,gulp那么您只需键入npm test它,它将运行本地gulp.

我从来没有在全球范围内安装gulp - 我认为这是糟糕的形式.

  • 比将它放在路径中更好的方法是使用NPM脚本 (3认同)