如何使Grunt Deploy使用全局NPM模块而不是本地模块
首先，我对npm和grunt很陌生。 我们有一个项目，我们正在使用Grunt来编译和生成输出文件。 我正在尝试设置我们的构建服务器以使用Grunt生成输出文件。 我们使用Windows与TFS源代码控制，并且由于它有260个字符路径限制，我们无法将grunt-bower-task模块检入源代码控制（因为它在其安装路径中使用了230个字符）。
当我从我的项目目录运行npm install时，它工作正常，并将以下必需模块安装到我的项目目录中的node_modules文件夹中：
然后当我从我的项目目录运行grunt deploy时，一切都按预期工作。
尽管我只是简单地将运行npm安装为构建过程的一部分，但我不愿意，因为它需要几分钟才能下载所有文件，而且我不希望我们的构建依赖于可用的外部Web服务。
我已经看到，您可以在本地或全局安装模块，所以我希望能够在生成服务器上全局安装模块，以便它们不需要直接在项目目录内的node_modules文件夹中运行grunt部署。 我为上面列出的每个模块以及npm install -g grunt-cli运行了npm install -g，以及npm install -g [module]。
如果我使用npm前缀-g，它会告诉我全局模块目录是C： Users [我的用户] AppData Roaming npm，当我查看该目录的node_modules文件夹时，我会看到所有模块。 但是，当我运行grunt部署时，它会抱怨：
致命错误：无法找到本地咕噜声
如果我只包含* node_modules grunt *目录，那么我仍然会遇到这些错误：
未找到本地Npm模块“grunt-contrib-watch”。 它是否安装？
未找到本地Npm模块“grunt-contrib-jshint”。 它是否安装？
...
我也尝试过使用* grunt deploy --base“C： Users [我的用户] 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"
}
}
谢谢。
您应该在模块上使用符号链接，而不是使用npm的全局选项来实现类似的结果。
全局npm安装只是为了方便命令行工具，如jshint或grunt-cli 。
解决方法：明确列出您自己的package.json中的所有临时依赖项。
比如说，你依赖于module_a，而module_a依赖于module_b。 npm install后，您将拥有node_modules/module_a/node_modules/module_b/因为npm会将module_b本地安装到module_a。 但是，如果将module_b作为package.json中的直接依赖项添加（并且版本说明符完全匹配），那么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（使用module_a使用的package.json中的确切版本字符串），那么npm会注意到它可以使用相同版本的module_b。 所以它只会在顶层安装module_b，而不是在module_a下安装。
长话短说：将具有深度模块树的任何瞬态依赖直接添加到您自己的package.json中，并且最终将获得更浅的node_modules树。
我使用窗体解决方案来解决Windows上的这类问题。 即使它适用于Git，如果您在Team Explorer中使用Visual Studio中的Git集成，即使您的node_modules文件夹中存在长文件路径，它仍然会崩溃 - 即使您并未将该文件夹添加到源代码管理中。
通常Grunt和Bower依赖结构会导致这种情况。
我建议的第一件事是在包装上运行npm dedupe 。 这样做的目的是扫描已安装的软件包，并查看是否有重复的依赖关系。 如果在更高级别上找到，它将删除深度测试的。
其次，如果重复数据删除无法解决问题，如果您可以找到导致此问题的嵌套深度较大的依赖关系，请尝试将其直接安装到解决方案中，然后再次运行重复数据删除。
如果有更多的软件包依赖导致这种情况，那么开窗可以解决这个问题。 加上它非常酷，因为你可以将它挂接到你的npm install上，它会在安装新的软件包后运行。 此外，它是完全可逆的。
我希望这有帮助。
链接地址: http://www.djcxy.com/p/65825.html上一篇: How to make Grunt Deploy use global NPM modules instead of local ones