Согласованный процесс сборки проекта Bootstrap - PullRequest
0 голосов
/ 30 апреля 2018

Для веб-приложения ASP.Net мы после некоторого рассмотрения решили обновить пользовательский интерфейс. Мы переходим с древней версии jQuery.UI на Bootstrap (v.3). Внешность мудрая, мы счастливы, и это было достаточно легко, чтобы это произошло.

Мы используем Less и Sass, чтобы упростить использование переменных для цветов и таких свойств. Это также отлично работает.

Но теперь к моей заботе. Процесс сборки для настройки Bootstrap включает в себя такой длинный список компонентов. Итак, мы имеем (это в Visual Studio 2017): НПМ NodeJS хрюкать Беседка NPM Task Runner (чтобы запустить grunt в VS) 452 (!!) модуля в каталоге node_modules

Как, черт возьми, вы делаете, чтобы сохранить это последовательным, т.е. поскольку npm update потенциально загружает новые версии node, grunt, любой из модулей и т. д. Конечно, нужно, чтобы сборка в любой среде сборки приводила к одинаковому результату, что обычно никогда не было проблемой до этого изменения, но теперь это выглядит как огромный риск. Наш сервер сборки Jenkins на самом деле тоже не играет, поэтому нам все еще нужно иметь выходные данные css / js в системе версий, чтобы сервер сборки мог построить решение.

Не могли бы вы: 1. Разбить загрузчик на отдельное решение (или конфигурацию) Visual Studio и всегда фиксировать полученные css / js и видеть этот вывод как «master»? Это кажется заманчивым в данный момент. В этом случае Дженкинсу не нужно было бы знать, как его собирать или загружать модули и т. Д. Но это противоречит принципу управления версиями только входных данных процесса сборки.

  1. Другие решения (не требующие жесткого кодирования номера версии во всех 452 файлах package.json)

Спасибо за любой вклад.

...