Lesezeit 8 Minuten

Im ersten Teil (Lokale Entwicklungsumgebung mit Joomla!) haben wir vorgestellt, wie Sie eine lokale Entwicklungsumgebung mit Laragon installieren und konfigurieren können und wie Sie mit Joomla! Ihre Webprojekt anlegen. Im folgenden Teil erkläre ich, wie Sie Node.JS und das SASS-Compiling installieren und konfigurieren, wie Sie SCSS bei Änderungen automatisch kompilieren und Browser-Sync installieren und konfigurieren.

Inhaltsübersicht

Installation und Konfiguration von NodeJS / npm

Installation von NodeJS inkl. npm

NodeJS ist im Grunde eine auf JavaScript basierende Laufzeitumgebung und bietet uns die Möglichkeit über den Node Package Manager (npm) Pakete / Abhängigkeiten zu installieren. In diesem Artikel möchten wir nicht zu detailliert auf die Funktionsweise von NodeJS und dem NPM eingehen, NodeJS bietet hierzu eine deutschsprachige Dokumentation, in die man sich bei Bedarf gerne einlesen kann.

Beginnen wir mit der Installation von NodeJS. Wir haben uns hier für die „Long-Term-Support“ (kurz LTS) Version entschieden. Diese ist für die meisten Anwender die passende Version.

Im Installationsassistenten können wir die Standardeinstellungen beibehalten und klicken uns entsprechend bis zum Ende durch. Während der Installationsroutine wird auch der benötigte NPM installiert.

abbildung 23 - Installation von NodeJS_

Nachdem die Installation abgeschlossen ist, starten wir unsere IDE und öffnen unser zuvor angelegtes Projekt.

Projekt initialisieren

Um NodeJS nun nutzen zu können, müssen wir unser Projekt dafür initialisieren. Dies können wir ganz einfach über das integrierte Terminal vollziehen. Wir öffnen das Terminal und tragen dort den Befehl „npm init“ ein und bestätigen die Eingabe mit „Enter“.

Abbildung 24 - Befehl NPM_Init

Die Routine möchte nun ein paar Informationen von uns haben, die wir entsprechend ausfüllen oder mit „Enter“ durchklicken können. Dies spielt für die Funktionsweise keine Rolle. Nachdem das Projekt erfolgreich initialisiert wurde, befindet sich eine neue Datei mit dem Namen „package.json“ im Projektordner. Die „package.json“ ist nun unsere Konfigurationsdatei für die nachfolgenden Schritte. Schauen wir uns den Inhalt der Datei doch einmal an:

Abbildung 25 - NPM_PackageJson Standard

Der Übersicht halber löschen wir ein paar Informationen die wir nicht benötigen:

Abbildung 26 - NPM_PackageJson Gekuerzt

Installation und Konfiguration von node-sass für das SASS-Compiling

Installieren wir nun unser erstes Paket „node-sass“. Dazu wechseln wir wieder in unser Terminal und führen dort „npm install -D node-sass“ aus. Erklären wir den Befehl einmal kurz:

  • npm“ verweist darauf, dass wir den NodePackageManager verwenden möchten.
  • install“ verweist darauf, dass wir ein Paket installieren möchten.
  • -D“ verweist darauf, dass es sich bei diesem Paket um eines handelt, was wir nur für die Entwicklung benötigen. „-D“ kann auch durch „—save-dev“ ersetzt werden.
  • node-sass“ ist der Name des Pakets, welches wir installieren möchten.

Nach der Installation des Pakets schauen wir uns doch direkt einmal unsere „package.json“ an:

Abbildung 27 - NPM_PackageJsonNodeSass

Wir sehen, dass in Zeile 6 der Bezeichner „devDependencies“ dazugekommen ist. Hier werden nun alle Pakete installiert, die wir ausschließlich für die Entwicklung benötigen.

Zudem finden wir nun einen neuen Ordner „node_modules“ in unserem Rootverzeichnis. Hier speichert NodeJS die benötigten Module / Pakete.

Nun haben wir „node-sass“ erfolgreich installiert, aber wozu brauchen wir „node-sass“ überhaupt? Wie der Name vermuten lässt, handelt es sich hier um ein Paket mit dem wir SASS/SCSS kompilieren können.

Wollen wir dies doch direkt mal testen. Hierzu legen wir uns eine Ordnerstruktur für unsere Entwicklungsdateien an. Wir nutzen gerne einen Ordner mit dem Namen „development“ im Rootverzeichnis unseres Projektes, welchen wir nun anlegen. In diesem Ordner erstellen wir noch einen Unterordner „scss“, wo wir dann unsere einzelnen .scss-Dateien hinterlegen.

Ein großer Vorteil von SCSS ist die Verwendung von Variablen, welche wir gerne in eine separate Datei auslagern. Hierzu legen wir uns eine Datei mit dem Namen „_variables.scss“ in dem Ordner „scss“ an und füllen diese mit unseren gewünschten Variablen:

Abbildung 28 - NPM_Variablen

Speichern wir die Datei mit „STRG+S“ einmal ab. Da wir unsere SCSS-Dateien gerne strukturieren, legen wir im Ordner „scss“ noch einen weiteren Unterordner „partials“ an. In diesem Ordner legen wir dann unseren ersten Teilbereich der Homepage an, z. B. „_layout.scss“. In dieser Datei wollen wir grundlegende Definitionen zum Layout hinterlegen, wie die Schriftfarbe von Links, die allgemeine Schriftgröße und die Gestaltung von Überschriften. Dies haben wir schon einmal vorbereitet:

 

abbildung 29 -NPM_Layout SCSS

In diesem Beispiel sehen wir auch direkt, wie wir unsere zuvor angelegten Variablen nun aktiv nutzen können.

Da wir für die Kompilierung nun noch einen Einstiegspunkt benötigen, erstellen wir uns im Ordner „scss“ noch eine Datei mit dem Namen „main.scss“. Innerhalb dieser Dateien importieren wir alle von uns angelegten Dateien, dies geht wie folgt:

Abbildung 30 - NPM_Main SCSS

Euch ist nun sicherlich aufgefallen, dass in der „@import“-Funktion die Unterstriche der Dateinamen nicht auftauchen, was hat es damit auf sich? Mit dem Unterstrich vor einem Dateinamen weiß SASS, dass es sich hier im ein Teilskript und nicht als eigenständige .css-Datei behandelt wird. Auch die Dateiendung .scss wird bei der Importfunktion nicht benötigt.

Speichern wir all unsere Dateien nun einmal ab und überprüfen wir unsere neu angelegte Ordnerstruktur, die nun wie folgt aussehen müsste:

  • development
    • scss
      • partials
        • scss
      • scss
      • scss

Wie kompilieren wir das Ganze nun und machen aus den einzelnen .scss-Dateien unsere gewünschte „user.css“? Hierzu benötigen wir unsere „package.json“ wieder. „node-sass“ kann man direkt über das Terminal aufrufen, da wir diesen Befehl aber häufiger benötigen, hinterlegen wir uns das Skript „node-sass development/scss/main.scss templates/protostar/css/user.css“ im „scripts“-Block unserer „package.json“ Datei und geben diesem Skript noch einen Wunschnamen „css:build“.

Abbildung 31 - NPM_ScriptNodeSass

Erklären wir das Ganze einmal:

  • css:build“ ist der freiwählbare Name unseres Skripts.
  • node-sass“ ist das Paket welches wir verwenden möchten.
  • development/scss/main.scss“ ist der Pfad zu unserer Haupt-SCSS Datei.
  • templates/protostar/css/user.css“ ist die Ausgabedatei. Protostar erkennt es, wenn eine „user.css“ hinterlegt ist und bindet diese automatisch ein, ohne das im Quellcode des Templates etwas verändert werden muss.

PhpStorm bietet nun mehrere Möglichkeiten NPM-Skripte auszuführen. Im Screenshot sieht man nach der Zeilennummer 6 ein grünes Playsymbol welches man anklicken und mit einem Klick auf „Run ‘css:build (npm)‘“ ausführen kann. Mit einem Rechtsklick auf unsere „package.json“ Datei kann man im Dialog „Show npm Scripts“ auswählen und erhalten ein neues integriertes Fenster in unserer IDE.

Abbildung 32- NPM_ScriptsIDE

In diesem Fenster finden wir dann alle von uns angelegten Skripte und mit einem Rechtsklick auf das jeweilige Skript können wir dieses starten. Bevor wir die Kompilierung starten, schauen wir uns unsere Joomla-Instanz noch einmal im Frontend an:

Abbildung - Frontend Joomla-Instanz

Starten wir nun in unserer IDE das Skript „css:build“ und warten, bis dieses erfolgreich ausgeführt wurde. Wir erhalten die Meldung „Rendering Complete, saving .css file… Wrote CSS to C:\laragon\www\haug-it\templates\protostar\css\user.css“. Laden wir unser Frontend einmal neu und schauen, ob schon etwas passiert ist:

Abbildung 33 - NPM_Frontend

Wie wir sehen, hat alles problemlos funktioniert. Die Links werden nun in unserer Wunschfarbe Orange dargestellt und die Überschrift H1 in Großbuchstaben und ebenfalls in der Farbe Orange.

Automatische Kompilierung von SCSS bei Änderungen

Damit wir nicht bei jeder kleinen Änderung unser Skript ausführen müssen, können wir die Änderung an unseren SCSS-Dateien beobachten lassen. Hierzu benötigen wir noch ein weiteres Skript. Diesen nennen wir „css:watch“ und befüllen es mit dem Inhalt „npm run css:build — -w“.

Abbildung 34 - NPM_ScriptWatch

Mit einem Rechtsklick in unser „npm“-Fenster und der Auswahl von „Reload Scripts“ erscheint nun unser neues Skript „css:watch“ was wir in bekannter Weise starten.

Abbildung 35 - NPM_WatchStart

Das Skript läuft nun so lange, bis wir unsere IDE beenden oder das Skript mit einem Klick auf das rote Stopsymbol stoppen. Was passiert, wenn wir nun eine Änderung an unseren SCSS-Dateien vornehmen? Testen wir das doch einmal und ändern in unserer „_layout.scss“ den Parameter für die Überschrift von „color: $orange;“ in „color: $black;“, speichern diese Datei ab und beobachten unser Fenster vom Skript:

Abbildung 36 - NPM_WatchAenderung

Das sieht doch schon einmal gut aus, wenn alles funktioniert, müsste unsere Überschrift im Frontend nun wieder schwarz sein. Laden wir das Frontend einmal neu und prüfen dies direkt:

Abbildung 37 - NPM_WatchFrontend

Sehr gut!

Da wir gerne mit mehreren Monitoren arbeiten, wäre es doch eine Erleichterung, wenn wir nicht jedes Mal manuell unser Frontend neu laden müssten um unsere Änderungen zu sehen. Das brauchen wir auch nicht! Hierbei hilft uns das Paket „browser-sync“ welches wir nun in unser Projekt integrieren und konfigurieren.

Browser-Sync installieren und konfigurieren

In gewohnter Weise installieren wir uns nun das Paket „browser-sync“. Da wir dies in all unseren Projekten nutzen wollen, können wir dieses global auf unserem Computer installieren. Hierzu führen wir in unserem Terminal folgenden Befehl aus: „npm install -g browser-sync“. Der Parameter „-g“ gibt an, dass es sich hier um eine globale Installation handelt. Nach der Installation sehen wir, dass auch keine Änderung an unserer „package.json“ vorgenommen wurde, das ist auch richtig.

Als nächstes benötigen wir noch eine Konfigurationsdatei die wir in unserem Rootverzeichnis ablegen. Hierbei handelt es sich um eine Konfigurationsdatei auf JavaScript-Basis, welche wir „bs-config.js“ nennen. Der Inhalt der Datei:

module.exports = {

"ui": {
"port": 3001
},
"https": false,
"files": "templates/protostar/",
"watchEvents": [
"change",
"unlink"
],
"watch": true,
"ignore": [],
"single": false,
"watchOptions": {
"ignoreInitial": true
},
"server": false,
"proxy": {
"target": "http://haug-it.test"
},
"port": 3000,
"middleware": false,
"serveStatic": [],
"ghostMode": {
"clicks": true,
"scroll": true,
"location": true,
"forms": {
"submit": true,
"inputs": true,
"toggles": true
}
},
"logLevel": "info",
"logPrefix": "DevServer",
"logConnections": false,
"logFileChanges": true,
"logSnippet": true,
"rewriteRules": [],
"open": "local",
"browser": "default",
"cors": false,
"xip": false,
"hostnameSuffix": false,
"reloadOnRestart": true,
"notify": false,
"scrollProportionally": true,
"scrollThrottle": 0,
"scrollRestoreTechnique": "window.name",
"scrollElements": [],
"scrollElementMapping": [],
"reloadDelay": 0,
"reloadDebounce": 1000,
"reloadThrottle": 0,
"plugins": [],
"injectChanges": true,
"startPath": null,
"minify": true,
"host": null,
"localOnly": false,
"codeSync": true,
"timestamps": true,
"clientEvents": [
"scroll",
"scroll:element",
"input:text",
"input:toggles",
"form:submit",
"form:reset",
"click"
],
"socket": {
"socketIoOptions": {
"log": false
},
"socketIoClientConfig": {
"reconnectionAttempts": 50
},
"path": "/browser-sync/socket.io",
"clientPath": "/browser-sync",
"namespace": "/browser-sync",
"clients": {
"heartbeatTimeout": 5000
}
},
"tagNames": {
"less": "link",
"scss": "link",
"css": "link",
"jpg": "img",
"jpeg": "img",
"png": "img",
"svg": "img",
"gif": "img",
"js": "script"
},
"injectNotification": true

};

In Zeile 6 muss der Pfad zu unserem Template eingetragen werden, in unserem Fall also „templates/protostar/“. Dies sorgt dafür, dass alle Änderungen innerhalb dieses Ordners beobachtet werden. Tritt eine Änderung ein, wird der Browser neu geladen. In Zeile 19 muss dann noch unsere erstellte URL eingetragen werden, in unserem Fall „http://haug-it.test“.  Weitere Erklärungen zu den einzelnen Parametern kann man der offiziellen Dokumentation von browsersync.io entnehmen.

Speichern wir unsere „bs-config.js“ nun einmal ab und widmen uns wieder der „package.json“. Hier müssen wir nun ein weiteres Skript hinzufügen und geben es den Namen „dev:browser-sync“ mit dem Inhalt „browser-sync start –config bs-config.js“.

Abbildung 38 - NPM_ScriptBrowserSync

Speichern wir unsere Datei einmal ab und führen erneut einen Rechtsklick in unserem „npm“-Fenster aus, um die Skripte neu zu laden und führen direkt unser neues Skript „dev:browser-sync“ aus.

Das Skript öffnet einen neuen Tab in unserem Browser und ruft die Seite „http://localhost:3000“ auf. Schauen wir uns nun unser Skriptfenster in Phpstorm einmal an:

Abbildung 39 - NPM_BrowserSyncStart

Ganz unten sehen wir, dass der „DevServer“ unsere Dateien beobachtet. Zusätzlich läuft unser Skript „css:watch“ auch im Hintergrund. Schauen wir doch einmal was passiert, wenn wir nun unsere Überschrift wieder in Orange darstellen möchten. Dazu ändern wir erneut den Parameter von „color: $black;“ in „color: $orange;“ und speichern die Datei. Was passiert?

Abbildung 40 - NPM_BrowserSync Aenderung

Unser Skript hat die Änderung erkannt und hat den Browser neu geladen. Wechseln wir nun also zu unserem Browser und schauen uns das Frontend einmal an, werden wir feststellen, dass die Überschrift nun wieder in orange angezeigt wird, ohne dass wir die Seite manuell neu laden mussten.

Abbildung 41 - NPM_BrowserSyncReload

Unsere Templateentwicklung kann beginnen!

Mit NPM kann man seinen Workflow noch weiter optimieren und Funktionen wie „Autoprefix“, „Minimierung von CSS- und JS-Dateien“, „Komprimierung von Bilddateien“ und „zusammenfügen von JS-Dateien“ nutzen.

Gerne gehen wir ein anderes Mal genauer darauf ein.

Tonino Gerns

Tonino Gerns ist gelernter Fachinformatiker für Systemintegration mit starkem Fokus auf die Webentwicklung. Bei der Haug IT-Solutions wird zum größten Teil mit dem Content Management System Joomla! gearbeitet. Als Projektinitiator des Joomla! Template Override Community Projects ist es uns wichtig, das Bestmögliche aus dem Joomla! Core herauszuholen.
Tonino Gerns

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Die von Ihnen hier erhobenen Daten werden von der Host Europe GmbH zur Veröffentlichung Ihres Beitrags in diesem Blog verarbeitet. Weitere Informationen entnehmen Sie bitte folgendem Link: www.hosteurope.de/AGB/Datenschutzerklaerung/