Менеджмент front-end зависимостей на Ruby

#ruby #gems #dependencies

Здравствуйте. Пишу программу с выводом в браузер. Для нее (помимо rubygems) нужно
несколько зависимостей: CSS, шрифты, JavaScript библиотека. Надо организовать управление
зависимостей, в первую очередь хотя бы скачивание по команде.
Варианты, которые я придумал:


Это может организовать Bower, но, так как программа распространяемая, не хотелось
бы заставлять пользователей устанавливать помимо Ruby еще и Node.js только чтобы загрузить
зависимости.
Можно распространять прямо с программой, но программа будет в Open Source на GitHub,
а засовывать чужие проекты в свой репозиторий, пусть даже и с дисклеймером, как-то
неудобно. Плюс самому придется следить за версиями каждой библиотеки и делать отдельный
commit под каждую версию каждой зависимости.
Можно сделать это через Rake + GitHub + Net::HTTP + File.write, но это как-то ненадежно
и займет дополнительную кучу кода, который надо поддерживать
Gem обертки, как известно, почти никогда никем не обновляются


Есть еще пара идей, но они на данный момент не кажутся реализуемыми:


Bower, увы, не предоставляет публичного Web API
CDN не вариант, так как программа, опять же, распространяемая и должна работать и
без подключения к интернету
Gem под данную задачу не нашел (подробнее ниже)


Пробовал также искать gem, но результаты плачевны:


giternal и rip позволяли загружать зависимости c git репозиториев, но они давно никем
не поддерживаются и не проходят большинство тестов
rails-assets и torba только для sprockets, а мне не хочется переписывать весь проект
под гем, который, слишком мягко говоря, мне совершенно не нравится.

    

Ответы

Ответ 1

В фронтэнде Node.js крепко укоренился для сборки и преобразования всего и вся. Поэтому
требовать установленный Node.js для модификации ассетов это дело нынче вполне обычное.
Посему, для полной среды разработки под ваш проект Node.js всё равно понадобится. Бежать
от него бесполезно — догонит.

Для вас в основном стоит задача "не заставлять конечных пользователей ставить Node.js,
т. к. во время выполнения он уже не нужен". Но конечные пользователи скорее возьмут
готовую сборку, чем будут делать её сами, и если в готовых сборках ассеты уже собраны,
то и Node.js им не понадобится. Следовательно, задача уже решена.

git clone не предназначен для распространения сборок. Вот совсем.



Если вас нервирует необходимость заставлять даже ради разработки исключительно серверной
части ставить зависимости ассетов, то можно сделать ход конём и вынести их в отдельный
гем. А при генерации конфигов для вебсервера (или настройке встроенного) можно узнать,
куда гем с ассетами установлен (на примере activesupport):

# они работают немножко по-разному, вас интересует скорее первое
Bundler.rubygems.find_name('activesupport').first.full_gem_path
Gem::Specification.find_by_name('activesupport').gem_dir


Это может иметь смысл где ассеты и серверная часть очень слабо связаны друг с дружкой,
если ассеты образуют что-то SPA-подобное, например.

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