Проблемы с размером пути, связанные с работой с узлом/npm на сервере сборки

Question

У меня есть сервер сборки, который строит и развертывает среду непрерывной интеграции (CI) и автоматически развертывает в Development, Staging, Live - все через определения сборки TFS ,

На сервере сборки мне нужно скомпилировать шаблоны пыли (до этапа развертывания) с помощью утилиты (dustc), загруженной с помощью Dust. Локально, когда я запускаю Visual Studio, Dust загружается, когда Visual Studio (VS) запускается в папку node_modules, однако эта папка обычно не проверяется (в противном случае многочисленные библиотеки на стороне клиента с версиями быстро приводят к издержкам управления)

Пыль загружается через npm (я использую v3.5.2). Как я понимаю, стандартный способ загрузки модулей, которые используют НПМ для загрузки выглядит следующим образом: -

• локально (в VS) скачать НПМ через NuGet, что приводит к папке в корневом каталоге проекта (». bin "), который содержит npm.cmd, который включен в проект и зарегистрирован
• , затем на сервере сборки после того, как были загружены артефакты решения/проекта, затем загружаются пакеты NuGet (включая npm)

• , наконец, отправьте следующие команды (в этом случае у меня есть это в задаче пост-сборки VS, но до тех пор, пока это происходит после загрузки пакетов NuGet, все должно быть ОК)

  cd "$(ProjectDir)" 
  call "$(ProjectDir)\.bin\npm.cmd" install dustjs-linkedin --save-dev 
  

Конечный результат «должен» быть Пыль загружается в структуру проекта (в папке node_modules), а затем я могу выдать команду для компиляции шаблонов Dust

Однако проблема в том, когда npm загружается с помощью NuGet, структура папок npm является массово вложенной и, следовательно, удаляет ограничение на характер в конце пути к Windows (https://github.com/nodejs/node-v0.x-archive/issues/6960) - следовательно, сборка не выполняется даже до того, как у задания была возможность запустить npm для загрузки Dust (примечание: у меня есть уменьшил длину папок TFS, однако npm оставляет очень мало места для любого разделения имен сборки, проектов и т. д. - например. .../пакеты/Npm.3.5.2/node_modules/НМП/node_modules/NPM-установки-чеки/node_modules/npmlog/node_modules/являются: мы-там еще/node_modules/читаемым-поток/node_modules/ядро-util- is/lib составляет около 170 символов)

Я читал Node npm windows file paths are too long to install packages, в котором предлагается использовать verion 3.x или использовать npm-flatten/dedupe, но у меня все еще возникают проблемы - главным образом потому, что это шаг NuGet, сбой - до того, как он сможет что-либо сделать с помощью npm

Решение может состоять в том, чтобы выбирать только файлы, которые необходимы (то есть из npm или, возможно, проще [но менее гибкие] будут просто файлами пыли [dustc, etc ]) и включить в исходный контроль и не включать npm в NuGet. Но это грязно - если файлы, которые я проверил, обновляются (как это часто бывает), я должен убедиться, что все еще нет в наличии и работает

Есть ли более чистый способ?

Answer 1

Несмотря на то, что ограничение длины пути действительно раздражает, самый эффективный и простой способ по-прежнему тратить некоторое время на создание вашей структуры файлов/папок, чтобы сделать эту работу.

Например: вместо \xx\Build\Drop\ProjectName, просто используйте \xx\Build\Drop (или \xx\Builds), так как название проекта также во имя сборки.

Для проблемы с длинными дорожками в TFS произошел соответствующий сервис и теперь завершен.

Fix 260 character file name length limitation

Мы сняли ограничение с BCL для основного файла функциональности манипуляции (CRUD). Вы можете найти более подробную информацию здесь:

https://blogs.msdn.microsoft.com/dotnet/2016/08/02/announcing-net-framework-4-6-2/

IMMO Landwerth менеджер программы .NET

Answer 2

Обратитесь к этим шагам и проверьте результат:

1. Установка Node.js к вашей сборке сервер
2. Добавьте файл конфигурации npm в свой проект (pa ckage.json) и проверить в
3. Откройте ваше определение сборки
4. Добавить НПМ шаг
5. Очередь строить