maven, bower, grunt – best pratices

Grunt ist ein Tool aus dem NodeJs Umfeld. Damit kann man super so Sachen wie minifying und das Zusammenfassen von Dateien per Script erledigen. Das möchte ich natürlich machen, aber ich hab dazu verschiedene Ansätze gefunden, die ich hier mal weiter auseinander nehmen möchte.

Grundsätzlich gehe ich hier von einer Anwendung aus, die viel clientseitiges JavaScript enthält, z.B. eine Angular-App. Je nachdem wie man den Code da in Controllern, Views usw. strukturiert kommen da schnell ein paar Files zusammen. Außerdem noch eine Reihe Biblitheken wie JQuery und natürlich das AngularJS Framework mit diversen Extensions dazu. Außerdem arbeite ich mit Maven und möchte, dass Grunt von Maven im Rahmen des normalen Builds ausgeführt wird. Ich hab dazu etwas gegoogled und habe zwei wesentliche Ansätze gefunden:

Möglichkeit 1: Grunt über einen Grunt-Watcher-Prozess bei Dateiveränderungen neu ausführen. Das wird so bei dem maven-grunt-plugin beschrieben: Hier

Das bedeutet, dass bei einer Änderung an einer CSS oder JS Datei dies durch den Watch-Prozess bemerkt wird und dieser dann grunt ausführt und damit neue Versionen der komprimierten und zusammengefassten von meinem lokalen Server ausgeliefert werde. Grunt ist wirklich ziemlich schnell und meistens dauert ein Lauf nur 3 Sekunden. In meiner Konfiguration ist es allerdings so, dass nachdem grunt gelaufen ist auch noch der Webserver merken muss, dass sich da was geändert hat und deshalb bin ich mir nicht immer sicher, ob ich da die richtige Datei bekommen habe. Außerdem sind komprimierte und zusammengefasste JavaScript-Dateien zum debuggen echt blöd, weil man seinen eigenen Quellcode nicht wiedererkennt und auch der Debugger macht wenig Sinn, wenn alles in einer Zeile steht. Das brachte mich auf Möglichkeit 2:

Möglichkeit 2: Arbeiten mit zwei Versionen. In der Entwicklerversion werden die “normalen” Dateien referenziert, nicht minified, nicht zusammengefasst. Beim build werden dann die Dateien zusammengefasst und die Referenzen geändert. Das wird von Matt Raible Hier beschrieben. Das hat den Vorteil, dass man ziemlich unbeeinflußt entwickeln kann, weil grunt ja erst zum Zuge kommt, wenn man deployed. Allerdings kann man hier das Problem bekommen, dass eine fehlerhafte grunt konfiguration dazu führt, dass der kram im Produktiv-System nicht mehr funktioniert. Das merkt man dann auch nicht mehr vorher, weil das System im lokalen Entwicklermodus ja auf den unkomprimierten Dateien arbeitet. Trotzdem ist Möglichkeit 2 mein Favorit. Ich möchte noch ausprobieren, ob man nicht mit Selenium basierten Tests eine Funktionalität der komprimierten Dateien während des Builds sicherstellen kann.

Ich mach jetzt mal weiter damit Möglichkeit 2 auszuprobieren. Zu den Selenium-Tests hier hoffentlich bald mehr…

 

Posted in Dies und Das

Leave a Reply

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

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>