27

首先，我对 npm 和 grunt 很陌生。我们有一个项目，我们正在使用 Grunt 为其编译和生成输出文件。我正在尝试设置我们的构建服务器以使用 Grunt 生成输出文件。我们正在使用带有 TFS 源代码控制的 Windows，并且由于它的 260 个字符路径限制，我们无法将 grunt-bower-task 模块检查到源代码控制中（因为它单独在其安装路径中使用 230 个字符）。

当我从我的项目目录运行npm install时，它工作正常并将以下所需模块安装到我的项目目录中的 node_modules 文件夹中：

  • 咕哝
  • 咕噜咕噜任务
  • grunt-contrib-compass
  • grunt-contrib-connect
  • grunt-contrib-jshint
  • grunt-contrib-requirejs
  • grunt-contrib-watch

然后当我从我的项目目录运行grunt deploy时，一切都按预期工作。

虽然我可以简单地将运行npm install作为构建过程的一部分，但我不想这样做，因为下载所有文件需要几分钟，而且我不希望我们的构建依赖于可用的外部 Web 服务。

我已经看到您可以在本地或全局安装模块，所以我希望能够在构建服务器上全局安装模块，这样它们就不需要直接位于项目目录内的 node_modules 文件夹中运行grunt deploy。我已经为上面列出的每个模块以及npm install -g grunt-cli运行了npm install -g和npm install -g [module]。

如果我执行npm prefix -g它显示全局模块目录是C:\Users[My User]\AppData\Roaming\npm，当我查看该目录的 node_modules 文件夹时，我确实看到了所有模块。但是，当我运行grunt deploy时，它会抱怨：

致命错误：无法找到本地咕噜声

如果我只包含 *node_modules\grunt* 目录，那么我仍然会收到以下错误：

未找到本地 Npm 模块“grunt-contrib-watch”。安装了吗？

未找到本地 Npm 模块“grunt-contrib-jshint”。安装了吗？

...

我也尝试过使用 *grunt deploy --base "C:\Users[My User]\AppData\Roaming\npm"，但它抱怨它找不到其他文件，例如 .jshintrc。

那么有没有一种方法可以运行grunt deploy并让它检查模块的 npm 全局前缀路径，而不是查看项目目录？

一个棘手的解决方法是在构建过程中手动将模块复制到本地项目目录，但如果可能的话，我想避免这种情况。

作为参考，这是我的package.json文件的样子：

{
  "name": "MyProject",
  "version": "0.0.1",
  "scripts": {
    "preinstall": "npm i -g grunt-cli bower"
  },
  "devDependencies": {
    "grunt": "~0.4.1",
    "grunt-contrib-compass": "~0.2.0",
    "grunt-contrib-watch": "~0.4.4",
    "grunt-contrib-jshint": "~0.6.0",
    "grunt-contrib-requirejs": "~0.4.1",
    "grunt-contrib-connect": "~0.3.0",
    "grunt-bower-task": "~0.2.3"
  }
}

谢谢。

4

5 回答 5

16

解决方法：在您自己的 package.json 中明确列出所有临时依赖项。

例如，假设您依赖于 module_a，而 module_a 依赖于 module_b。之后npm install你会node_modules/module_a/node_modules/module_b/因为 npm 将 module_b 安装到 module_a 的本地。但是，如果您在 package.json 中添加 module_b 作为直接依赖项（并且版本说明符完全匹配），那么 npm 只会安装 module_b 一次：在顶层。

这是因为当需要模块时，它们会开始查找最近的 node_modules 目录并向上遍历，直到找到所需的模块。因此 npm 能够通过仅在版本匹配的最低级别安装模块来节省磁盘空间。

所以，修改后的例子。您依赖于 module_a@0.1.0，它依赖于 module_b@0.2.0。如果您还依赖于 module_b@0.1.0，您最终会安装两次 module_b。（0.1.0 版将安装在顶层，0.2.0 版将安装在 module_a 下。）但是，如果您依赖 v0.2.0（使用 package.json 中的确切版本字符串作为 module_a 使用），那么npm 会注意到它可以使用相同版本的 module_b。所以它只会在顶层安装module_b，而不是在module_a下。

长话短说：将您拥有的任何具有深层模块树的瞬态依赖项直接添加到您自己的 package.json 中，您最终会得到一个更浅的node_modules树。

于 2013-12-30T15:17:33.203 回答
7

npm您应该在模块上使用符号链接，而不是使用全局选项，以获得类似的结果。

全局npm安装只是为了方便命令行实用程序，例如jshint, 或grunt-cli.

于 2013-11-05T18:00:12.940 回答
5

我知道这个线程很旧，但我终于找到了自己的个人答案，使用 Mac，但我认为同样可以用 PC 说/做。

跟进贝瓦夸的回答：

您应该在模块上使用符号链接，而不是使用 npm 的全局选项，以获得类似的结果。

全局 npm 安装只是为了方便命令行实用程序，例如 jshint 或 grunt-cli。

我做了一些挖掘，也许可以给出更多的澄清：

我最终在我的用户目录的根目录中创建了一个全局文件夹。在该目录中，我使用npm install. 因此，例如我运行npm install grunt、npm install grunt-contrib-watch、npm install grunt-contrib-less等。您还可以package.json在同一个文件夹中添加一个文件，然后运行npm install一次将它们全部添加。现在我的全局目录具有以下结构：

.global_grunt_modules
    node_modules
        grunt
        grunt-contrib-watch
        grunt-contrib-less

然后我转到需要运行 grunt 的任何工作项目目录，并在该文件夹的根目录中运行命令：

ln -s ~/.global_grunt_modules/node_modules .

ln带有-s（符号链接）标志的有两个参数：

[source_file] [target_dir]

所以命令基本上说，“从我的全局 node_modules 文件夹创建一个符号链接，并将其链接到我的当前目录”。指定当前.工作目录。

希望这会有所帮助，我也遇到了麻烦。然后，每当我有一个需要新 grunt 模块的项目时，我只需通过我的全局目录安装它，然后在创建符号链接的任何地方都可以使用该目录。

于 2015-07-10T18:06:20.823 回答
4

我使用fenestrate来解决 Windows 上的此类问题。即使它适用于 Git，如果您在团队资源管理器中使用 Visual Studio 中的 Git 集成，如果长文件路径位于您的 node_modules 文件夹中，它仍然会崩溃 - 即使您没有将该文件夹添加到源代码管理。

通常 Grunt 和 Bower 依赖结构会导致这种情况。

  1. 我建议的第一件事是npm dedupe在你的包上运行。这样做的目的是扫描您已经安装的软件包并查看是否有一些依赖项重复。如果在更高级别上找到，它将删除经过深入测试的那些。

  2. 其次，如果 dedupe 不能解决问题，如果您可以找到导致此问题的嵌套太深的依赖项，请尝试将其直接安装到您的解决方案中，然后再次运行 dedupe。

  3. 如果有更多的包依赖导致这个问题，fenestrate将解决这个问题。另外，它真的很酷，因为您可以将它挂接到您的 npm install 上，并且它总是会在安装新软件包后运行。此外，它是完全可逆的。

我希望这有帮助。

于 2014-11-22T01:14:12.333 回答
0

当 npm 链接不够好（网络文件系统，...）时，您可以使用'requireg'包。这是唯一一种以某种方式使其“内置”的干净解决方案。'requireg' 包有一个函数 globalize，它使后续的 require 调用也可以在全局范围内查找。

于 2016-03-13T19:05:15.350 回答