与在构建服务器上使用节点/npm相关的路径大小问题

Question

我有一个构建服务器，它构建并部署到我们的持续集成(CI)环境中，并通过TFS构建定义自动部署到开发、阶段、实况。

在构建服务器上，我需要通过Dust下载的实用程序(dustc)编译Dust模板(在部署步骤之前)。当我在Visual中运行时，当Visual (VS)启动到文件夹node_modules时，就会在本地下载Dust，但是该文件夹通常不会被签入(否则，具有版本的众多客户端库会很快导致管理开销)。

灰尘是通过npm下载的(我使用的是v3.5.2)。据我所知，使用npm下载模块的标准方法如下：

• 在本地(VS内)通过NuGet下载npm，从而在项目根目录下生成一个文件夹(".bin")，其中包含项目中包含并签入的npm.cmd。
• 然后，在构建服务器上，在解决方案/项目工件下载之后，然后下载NuGet包(其中包括npm)。
• 最后，提交以下命令(在本例中，我将它放在VS后期构建任务中，但只要在下载NuGet包之后就可以了)。 cd "$(ProjectDir)“调用"$(ProjectDir).bin\npm.cmd”安装dustjs-linkedin -save-dev

最终的结果“应该”被下载到项目结构中(在node_modules文件夹中)，然后我可以发出命令来编译Dust模板

然而，问题是当npm通过NuGet下载时，npm文件夹结构是大量嵌套的，因此破坏了Windows 260字符限制(https://github.com/nodejs/node-v0.x-archive/issues/6960) --因此构建甚至在作业有机会运行npm下载Dust之前就失败了(注意:我已经减少了TFS文件夹的长度，但是npm为任何构建名称、项目等的划分留下了很少的空间)。.../packages/Npm.3.5.2/node_modules/npm/node_modules/npm-install-checks/node_modules/npmlog/node_modules/are-we-there-yet/node_modules/readable-stream/node_modules/core-util-is/lib大约有170个字符)

我读过节点npm窗口文件路径太长，无法安装包。，它建议使用verion 3.x，或者使用npm --扁平/dedupe--但是我仍然有问题--主要是因为NuGet步骤失败了--在它能够对npm做任何事情之前。

一种解决方案可以是只选择需要的文件(例如，从npm，或者可能更简单但不太灵活的文件-沙尘文件，等等)--并且包括在源代码控制中，而不包括NuGet中的npm。但是这是很混乱的--如果我签入的文件被更新(就像它们经常更新的那样)，我必须确保所有文件都完好无损并运行。

有更干净的方法吗？

Answer 1

尽管路径长度限制确实令人讨厌，但最有效和最简单的方法仍然是花费一些时间来调整文件/文件夹结构以使其工作。

例如，：而不是\xx\Build\Drop\ProjectName，只需使用\xx\Build\Drop (或\xx\Builds)，因为项目名称也在构建名称中。

对于TFS中的长路径问题，有一个相关的uservoice，现在已经完成了。

修正260个字符文件名长度限制 我们已经从BCL中删除了对基本文件操作功能(CRUD)的限制。您可以在这里找到更多详细信息： https://blogs.msdn.microsoft.com/dotnet/2016/08/02/announcing-net-framework-4-6-2/ 项目经理.NET

Answer 2

请参考这些步骤并检查结果：

1. 将Node.js安装到构建服务器上
2. 将npm配置文件添加到您的项目(package.json)并签入
3. 打开构建定义
4. 添加npm步骤

​

1. 队列构建