У меня есть сервер сборки, который выполняет сборку и развертывание в нашей среде непрерывной интеграции (CI) и автоматически развертывается в средах разработки, промежуточной подготовки, эксплуатации — все через определения сборки TFS.
На сервере сборки мне нужно скомпилировать шаблоны Dust (перед этапом развертывания) с помощью утилиты (dustc), загруженной вместе с Dust. Локально, когда я запускаю в Visual Studio, Dust загружается при запуске Visual Studio (VS) в папку node_modules, однако эта папка обычно не проверяется (в противном случае многочисленные клиентские библиотеки с версиями быстро приводят к накладным расходам на управление)
Пыль скачивается через npm (у меня v3.5.2). Насколько я понимаю, стандартный способ загрузки модулей, использующих npm для загрузки, выглядит следующим образом:
- локально (внутри VS) загрузите npm через NuGet, что приведет к созданию папки в корне проекта ("".bin"), содержащей npm.cmd, который включен в проект и зарегистрирован
- затем на сервере сборки после загрузки артефактов решения/проекта загружаются пакеты NuGet (включая npm)
наконец, отправьте следующие команды (в этом случае у меня это есть в задаче после сборки VS, но пока это происходит после загрузки пакетов NuGet, все должно быть в порядке)
cd "$(ProjectDir)" call "$(ProjectDir)\.bin\npm.cmd" install dustjs-linkedin --save-dev
Конечным результатом должно быть: Dust загружается в структуру проекта (в папку 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 символов)
Я прочитал Пути к файлам окон Node npm слишком долго устанавливать пакеты, которые предлагают использовать версию 3.x или использовать npm-flatten/dedupe — но у меня все еще есть проблемы — в основном потому, что это шаг NuGet, который терпит неудачу — прежде чем он сможет делать что-либо с npm
Решение может состоять в том, чтобы выбрать только те файлы, которые необходимы (например, из npm или, возможно, проще [но менее гибко] будут просто файлы Dust [dustc и т. д.]) и включить в систему управления версиями, а не включать npm в NuGet. Но это грязно - если файлы, которые я проверяю, обновляются (как это часто бывает), я должен убедиться, что все по-прежнему не повреждено и работает.
Есть ли более чистый способ?
