[Symfony 2] AsseticBundle, Less CSS & YUI Compressor unter OSX installieren

Das AsseticBundle ist ein Wrapper um Assetic, ein geniales Tool, um statische Assets für Webprojekte zu verwalten. AsseticBundle ist extrem einfach zu verwenden, einfach die entsprechende Filter-Chain via yaml konfigurieren, um mehr muss man sich nicht kümmern. Natürlich allerdings müssen die zugrundeliegenden Abhängigkeiten im Vorfeld installiert sein. In unserem Falle benötigen wir den Yui-Compressor als jar-File und Less CSS. Less ist ein node.js Modul, was bedingt, dass wir zuvor node.js installieren müssen.

Also node.js via macports holen:

$ sudo port install nodejs

Und den node.js-eigenen Package-Manager:

$ sudo port install npm

Mit diesem installieren wir als nächsts less, und zwar “global” (via -g)-Flag (“global” bedeutet, dass das Modul unter $nodejs_lib_path/../node_modules abgelegt wird, ansonsten wird es im aktuellen Arbeitsverzeichnis unter ./node_modules installiert):

$ sudo npm install -g less

Damit haben wir alles, um unsere less CSS Stylesheets kompilieren zu können.

Als nächstes holen wir uns den Yui-Kompressor, diesen habe ich mir einfach aus dem Netz gezogen und unter app/java/yuicompressor-2.4.6.jar abgelegt (Die Binary findet ihr unter http://developer.yahoo.com/yui/compressor/).

Nun die Konfiguration:

app/config.yml:

# Assetic Configuration
assetic:
debug:          %kernel.debug%
use_controller: false
filters:
cssrewrite: ~
less:
node: /opt/local/bin/node
node_paths: [/opt/local/lib/node, /opt/local/lib/node_modules]
yui_css:
jar: %kernel.root_dir%/java/yuicompressor-2.4.6.jar

Zu beachten sind die “node_paths”. Der node.js-Modulpfad muss explizit angegeben werden, sonst kann node.js die require()-Statements nicht auflösen (das sind sozusagen die node.js-“Classpaths”). /opt/local/lib/node zeigt auf Core-Module, in /opt/local/lib/node_modules liegt unser less.

Um den Yui-Kompressor zu aktivieren, reicht der simple Pfad zur .jar-Datei.

Nun müssen wir nur noch unser Twig-Layout anpassen:

src/Nerdpress/DemoBundle/Resources/views/layout.html.twig:

<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
{% stylesheets
'@NerdpressDemoBundle/Resources/public/css/main.css'
'@NerdpressDemoBundle/Resources/public/css/layout.css'
filter='less,?yui_css'
combine=true
%}
<link rel="stylesheet" href="{{ asset_url }}" type="text/css" media="all" />
{% endstylesheets %}

Das “?” vor dem Filter “yui_css” bedingt, dass die CSS-Compression nur angeschaltet wird, wenn der Debug-Parameter auf false steht. “Combine” bedeutet, dass alle CSS-Dateien in einer einzigen, großen Datei zusammengefügt werden, und “less” bedeutet letztlich, dass alle CSS-Dateien mittels less CSS precompiled werden.

That´s it. Die Seite im Browser öffnen und das Ergebnis bewundern. Viel Spaß! Symfony ist schon was feines…

5 Replies to “[Symfony 2] AsseticBundle, Less CSS & YUI Compressor unter OSX installieren”

  1. Wenn man LESS o.ä. benutzt auf jeden Fall supercool.

    Ansonsten bin ich sowieso Fan vom YUI Compressor,
    aber ist Asset-Optimierung wirklich im PHP Code so gut aufgehoben?

    Habe den Assetic mal in einem Silex Projekt ausprobiert.
    …das geht übrigens entweder mit dieser Extension Kollektion, oder zum schnellen Rumprobieren auch per

    $app['autoloader']->registerNamespace('Assetic', __DIR__ . '/path_to_assetic/src');
    

    und dann eben von Hand, wie in der Assetic-Doku.

    Bei häufigen Änderungen ist Assetic aber schon spürbar im Debug Mode, wie ich finde – auch ohne Kompressor.
    Wie gesagt, für Dinger wie LESS ist das schon superpraktisch, aber die reine Asset Optimierung finde ich irgendwie besser im build/deploy-vorgang.
    Und dann von mir aus sogar lieber extern per shell, als im PHP Code…

    Oder übersehe ich einen Riesenvorteil, den man lokal von Assetic hat?

  2. – Spiel noch einmal unser Lied, Sam. -Ding Dong die Hex´ist tot, die Hex´ ist tot …

    Ich glaube, man hat die Wahl: Via $ app/console assetic:dump kann man das Zeug direkt ins Dateisystem schreiben, das bleibt dann auch da (auch mit debug=true).

    Ich denke, dass dieser on-the-fly-Mechanismus nur zum debuggen gut ist – ich hatte tatsächlich einige Probleme damit, z.B. funktionieren mit less @import url(“…”); Statements nicht – ist wohl ein bekannter bug. Ich habe es selbst noch nicht ausprobiert, gehe aber davon aus, dass wenn man gerade nicht am CSS frickelt, ein assetic:dump das ganze gut beschleunigen kann.

  3. Is mir noch nicht untergekommen, eigentlich sind alle Webassets in Bundles organisiert … Ansonsten würde ich mir aus dem DIC irgend einen Parameter suchen, der auf /web zeigt … im einfachsten Fall kernel.root_dir./../web

    Schön ist das aber nicht.

Leave a Reply

Your email address will not be published. Required fields are marked *