我有一个构建服务器，它构建并部署到我们的持续集成 (CI) 环境，并自动部署到 Development、Staging、Live——所有这些都通过 TFS Build Definitions 进行。
在构建服务器上，我需要通过随 Dust 下载的实用程序 (dustc) 编译 Dust 模板（在部署步骤之前）。在本地，当我在 Visual Studio 中运行时，当 Visual Studio (VS) 启动时会将 Dust 下载到文件夹 node_modules 中，但是通常不会签入此文件夹（否则带有版本的众多客户端库会很快导致管理开销）
Dust 是通过 npm 下载的（我使用的是 v3.5.2）。据我了解，下载使用 npm 下载的模块的标准方法如下：-
- 在本地（在 VS 中）通过 NuGet 下载 npm，这会在项目根目录（“.bin”）中生成一个文件夹，其中包含 npm.cmd，该文件夹包含在项目中并已签入
- 然后，在解决方案/项目工件下载后的构建服务器上，然后下载 NuGet 包（包括 npm）
最后，提交以下命令（在这种情况下，我在 VS 构建后任务中有它，但只要是在下载 NuGet 包之后，一切都应该没问题）
cd "$(ProjectDir)" call "$(ProjectDir)\.bin\npm.cmd" install dustjs-linkedin --save-dev
最终结果“应该”是 Dust 被下载到项目结构中（在 node_modules 文件夹中），然后我可以发出命令来编译 Dust 模板
然而问题是当通过 NuGet 下载 npm 时，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 个字符）
我读过Node npm windows 文件路径太长，无法安装建议使用版本 3.x 或使用 npm-flatten/dedupe 的软件包 - 但我仍然遇到问题 - 主要是因为 NuGet 步骤失败 -在能够用 npm 做任何事情之前
一个解决方案可能是只选择需要的文件（即从 npm 或可能更容易 [但不太灵活] 将只是 Dust 文件 [dustc 等]）并包含在源代码控制中，而不是在 NuGet 中包含 npm。但这很麻烦-如果我签入的文件已更新（通常是这样），我必须确保所有文件仍然完好无损并运行
有没有更清洁的方法？
