Серверный процессинг LESS файлов «на лету» своими руками

[biophreak]

А почему бы не генерить 1 раз из less файлов обычные css-ки? И подгружать, соответственно их.

[meta4]

В случаи разработки less файлы я постоянно правлю — по этому постоянно перегенерировать их неудобно. Да и для продакшена — зачем усложнять себе выкладку дополнительным шагом сборки, которого легко можно избеждать.

[Ganesh]

Ну так и разрабатывайте с динамической компиляцией в браузере, а на продакшене компилируйте при сборке приложения.

[meta4]

>Ну так и разрабатывайте с динамической компиляцией в браузере, а на продакшене компилируйте при сборке приложения.

Это значит что нужно в продакшене и в девелопменте эти части страницы будут различаться. К чему такие сложности если можно без этого обойтись?

[Ganesh]

А на кой черт на продакшене использовать не скомпилированный код? Может вы еще и на продакшене в режиме онлайн минифицируете и обфусцируете JS код? Мне почему-то больше кажется, что сложности написаны именно у вас.

[Holy_Cheater]

Да, я так и делаю. В cms, которую пользую на работе, есть фунционал который за меня минифицирует js/css. Я об этом даже не задумываюсь и не вспоминаю при правках. В чем сложность для меня-то?

[Ganesh]

Я конечно, могу процитировать весь топик, но мы же взрослые люди и умеем скролить.
У меня такое впечатление, что вы просто не знакомы с понятием сборки приложения (например maven, ant), и у вас возникает какие-то трудности в понимании, того что для решения проблемы достаточно добавить в сборку для продакшена этап компиляции css (в данном случае сборщик у вас наверное тот самый функционал). А уж простите править файлы на продакшене — это либо форс мажор, либо отсутствие мозга.

[mrjj]

лол, они почти всегда будут различаться и для этих случаев очень неплохо подходят штуки вроде fabric, куда полезнее будет ман по управлению ноды из fab, свежо и удобно.

[Coder]

… видел программу, которая автоматически перегенерирует LESS файлы при их изменении, но она оказалась платной и только под МакОСь.

LESS.app, winless, less,...?

[Coder]

Но да, не уверен про автоматическую компиляцию при изменении.

[meta4]

Ага, они. Мне подход с трансформацией на лету больше нравится — получается, как будто less поддерживается самим браузером, мне не надо думать о том у куда и во что генерируются эти самые .less файлы.

[cloud]

incron — автомтическое что угодно при изменении чего угодно
habrahabr.ru/blogs/linux/66569/ — статья на хабре про это

[mrjj]

Хм, у меня это 10 строчек кода маленького демона делают, а люди за это деньги берут ?!

[shaelf]

Люди берут за удобный интерфейс. Вообще идея УГ. Могу посоветовать почитать про мавен или ант:)

[rmaksim]

while true; do inotifywait -e modify css.less; lessc css.less > css.css; done;

[kroks]

Что если хранить в начале less файла строку хеша от файла (всех остальных строк), и если файл изменился, то только тогда заново генерировать?

[meta4]

Зачем? Изменение даты последнего имезенения файла в большинстве случаев должно хватать.

[Makito]

Недавно на хабре были статьи про Less, приводилась прога SimpLESS.
Бесплатна, работает на всех платформах, на лету отслеживает изменения и компилит их в css причем еще и минимизирует его.
Сейчас использую данную прогу на нескольких проектах, очень удобно, а на продакшн выкладываю чистый css

[meta4]

>Бесплатна, работает на всех платформах, на лету отслеживает изменения и компилит их в css причем еще и минимизирует его.

На счет минимизации — так это LESS штатно умеет, и мой сервер тоже. Но с моим подходом вообще не надо задумываться на чем пишешь — на less или css.

[Timosha]

incron + препроцессор less, и не придётся «запускать ручками» :) много проще чем сервер + прокси

[meta4]

>сервер + прокси

Так nginx я в любом случаи использую (и многие используют). Добавить пару строчек в нгинкс и запстуить одной командой сервер не сложнее чем добавить задачу в крон, а крон выполять надо будет очень часто — я быстро правлю+ переключась в браузер :)

[Timosha]

incron — это cron который срабатывает не по времени, а по событию, например, после модификации файла :)

[meta4]

Спасибо, не знал про его существование.

[maxx_es]

я сделал (не)множко по-другому:

etc/nginx/nginx.conf

perl_modules etc/nginx/perl;
perl_require lesscss.pm;

etc/nginx/perl/lesscss.pm

package lesscss;
use File::stat;
use nginx;

sub handler
{
	my $r = shift;
	
	$r->send_http_header("text/css");
	return OK if $r->header_only;
	
	if(-f $r->filename)
	{
		$less = $r->filename;
		$less =~ s/\"//g;
		$css = $less;
		$css =~ s/\.less$/.css/gi;
		
		if(!stat($css) || stat($less)->mtime > stat($css)->mtime)
		{
			system("PATH=/opt/local/bin lessc \"".$r->filename."\" > \"".$css."\"");
		}
		if(-e $css)
		{
			$r->sendfile($css);
			$r->rflush;
		}
	}
	
	return OK;
}

1;
__END__

etc/nginx/vhost/???

location ~* ^.+\.less$ { perl lesscss::handler; }

в итоге nginx сам смотрит за изменениями в .less-файле, и незаметно обновляет .css, лежащий тут же рядом.
решение не идеально, но для домашнего сервера пойдёт.

[kratkar]

Спасибо. Ваше решение самое то!

[cadmi]

Не делайте так. В nginx Perl не для этого. На тестовом сервере, куда никто кроме Вас не ходит, еще покатит. Но очумелые ручки же это «самое то» решение непременно на боевой выкатят.

[Sannis]

Расскажите, в чём подвох с Перлом?

[cadmi]

Во время выполнения perl внутри nginx, скриптом напрочь блокируется весь worker. Perl, встроенный в nginx — это совсем не то же самое, что mod_perl в Apache. Он не предназначен для генерации страниц, лазания в SQL, форкания процессов (как в вышеприведенном примере с вызовом system() и less) и т.п.

Встроен для удобства написания сложной логики обработки location или написания хитровывернутых rewrite теми, кому это действительно нужно. Чтобы не сковывать их ограничениями синтаксиса nginx.conf.

Ну максимум — что-то собрать из SSI.

[Sannis]

Спасибо :)

P.S. Хотя мне недавно попадалась статья на тему прикручивания libdrizzle к Nginx.

[cadmi]

Олег в рассылке (и, кстати, документации тоже) явным образом и черным по белому НЕ рекомендует сетевые обращения из встроенного Perl. Настойчиво предлагается «ограничиться операциями, время исполнения которых короткое и предсказуемое, например, обращение к локальной файловой системе».

[Sannis]

У нас ограничивается обращением по сокету к локальному MySQL с таблицей в памяти. Но думаю над тем, когда же это станет узким местом.

[cadmi]

Если человек знает, что делает и понимает, чем это грозит, то ничего страшного.

[cadmi]

Тьфу, блин. Игорь, конечно. Вредно в два окна сразу писать.

[AlexoLive]

Я себе hook сделал в Mercurial, и ничего лишнего)

[meta4]

Эээ. Это немного другое — не будете же во время разработки при изменении свойства «напосмотреть» коммититься.

[AlexoLive]

На посмотреть и js скрипт сойдет

[student_ivan]

Поделюсь своим решением github.com/studentIvan/Perl-LESS-Watcher

[cramen]

я в php проектах использую leafo.net/lessphp/
rewrite правила к css проверяют, есть ли less файл с аналогичным именем и если есть и дата модификации его позже, чем у css, то компилирую less в css
дальше вне зависимости от первого условия отдается содержимое css или ошибка 404, если его нету.

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

[shternberg]

Как мне кажется, гораздо разумней использовать для данных целей assetic – он позволяет налету компилировать LESS, SASS, Compas, сжимать css, javascript и многое другое.
Позволяет генерировать скрипты, как на лету, так и делать дамп на диск.

github.com/kriswallsmith/assetic

[mac2000]

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

[tonic]

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

[meta4]

>Такое решение из серии вредных советов. На боевом сервере нужно собирать css в момент деплоя.

Так вы напишите, чем плохо то. Зачем вообще собирать, а не на лету обрабатывать, с учтом того что кеширование все равно решает проблему производительности? Тот же python/php за то и любят, что его файлы собирать не надо. Nginx gzip-ает тоже налету. Почему же именно в этом случае должна быть сборка?

[VBart]

«Nginx gzip-ает тоже налету»
Расходуя процессорные ресурсы на каждый запрос, увеличивая latency. Кстати, nginx.org собирается make-файлом, генерация и сжатие всех страниц выполняется на этапе сборки.

Зачем расходовать ресурсы впустую?

«Тот же python/php за то и любят, что его файлы собирать не надо»
Не за это python любят. В сущности это, как раз, пустяк.

[achekalin]

Вообще для боевого деплоя есть make, а для тестового сервера — можно делать как угодно, да. Но тогда и less на клиенте не должен раздражать, он даже удобнее.

[biophreak]

Действительно, не проще будет написать Makefile, который будет делать все сам?
Я не только про конвертацию less в css, можете туда еще например проверку на ошибки в языке (для перла я юзаю Perl::Critic например, для ноды jslint), тесты в конце концов прикрутить.
Подготовку минифицированных js, гзип, объединение чего надо в 1 файл и так далее.

Например потом можно в .deb все упаковать и положить в репозиторий.
В бою-же просто apt-get update && apt-get install package.

[Tenphi]

github.com/Tenphi/node-jss

вдруг интересно будет)