Taskrunner Ade

Published
Start the Conversation
0 Comments

Taskrunner Ade

Wenn ein Taskrunner nur das Problem seines Vorgängers löst, sollten wir doch einfach den Taskrunner weglassen und die Probleme lösen.

Ein neues Projekt war an Horizont und es stellte sich die Frage: Wie bauen wir diesmal unser CSS und Javascript zusammen.
In der Vergangenheit waren zwei Anläufe mit webpack kläglich gescheitert und ich hatte jedesmal gulp verwendet.
Leider wird gulp nicht mehr weiter entwickelt und ich wollte nicht vorsätzlich ein eine alte Abhängigkeit in ein neues Projekt bringen
Grunt war mir zu langsam, also musste etwas Neues her.

get rid of grulpack (grunt / gulp / webpack)

Irgendwie bin ich während der Recherchen bei einem Blogartikel gelandet den ich leider nicht mehr finde, deshalb schreibe ich jetzt selbst etwas dazu.
Die Essenz der Artikels war: Warum überhaupt einen Taskrunner verwenden? Die Programme die wir benötigen haben in alle ein CLI-Interface. Alles andere ist überflüssiger Schnickschnack.

Also wollen wir uns mal anschauen, wie wir das alles ohne die üblichen Verdächtigen schaffen können.

Voraussetzungen

Für das ganze brauchen wir ausschließlich eine vernünftige node.js Version: Also 16+.

Ich bin ein großer Fan von nodenv []

Unser Projekt orchestrieren wir über npm und damit wir das Ganze auch in Build-Pipeline verwenden können, installieren wir alle Tools lokal. 
Das hat den weiteren Vorteil, dass wir nicht auf das Wohlwollen global installierter Varianten angewiesen sind.

CSS

Die einfachste Methode Sass im lokalen Projekt einzubinden geht so:

npm i sass
npx sass source/stylesheets/index.scss build/stylesheets/index.css

Um das Ganze ein bisschen komfortabler zu machen, können wir noch einen Befehl in unserer packages.json hinterlegen.

"script": {
	"build:css:development": "npx sass --embed-source-map source/stylesheets/index.scss build/stylesheets/index.css",
	"build:css:production": "npx sass --no-source-map source/stylesheets/index.scss build/stylesheets/index.css",
}

Die komplette Dokumentation findet sich hier:
https://sass-lang.com/documentation/cli/dart-sass

Javascript

Um schnell Javascript zusammen zu raffen, verwenden wir esbuild.

npm i esbuild
esbuild source/js/index.js --bundle --minify --sourcemap --plattform=browser --outdir=build/js

Damit man das Ganze einfacher bedienen kann, fügen wir das auch in die package.json ein:

"script": {
	"build:js:development": "npx esbuild source/js/index.js --bundle --minify --sourcemap --plattform=browser --outdir=build/js",
	"build:js:production": "npx esbuild js/index.js --bundle --minify --plattform=plattform --outdir=build/js",
}

Watcher

Javscript bietet dazu eine Fülle an Funktionen und Bibliotheken.

Als Frontendentwickler möchten wir aber unsere Dateien on-the-fly übersetzt haben. Dazu brauchen wir jetzt einen Watcher.

Natürlich könnnen wir hier auch einfach Browsersync verwenden. Aber das Ziel dieses Artikels ist, zu zeigen, dass ein Watcher kein Hexenwerk ist.

Man braucht dazu weder die erwähnten Taskrunner, noch eine IDE (vscode, phpstorm) oder etwas anderes. Und wenn es funktioniert, können wir das auf allen bekannten Desktopplattformen äußerst performant laufen lassen.

 

npm i node-watch

Dann schreiben wir eine kleine Javscript-Datei watch.js:

import Watch from 'node-watch'
import * as child from 'child_process'
const execSync = child.execSync
const watch = Watch.default

watch('./sass', {recursive: true}, (evt, name) => {
  console.log('sass triggered0'0)
  execSync('npm run build:css:development')
})

watch('./js', {recursive: true}, (evt, name) => {
  console.log('sass triggered0'0)
  execSync('npm run build:js:development')
})

Und starten das Ganze mit:

node watch.js

Warum das Ganze

Wage etwas neues: Schreibe dein Build-Tool selbst!

Der große Nachteil der aufgeführten Taskrunner ist meiner Meinung, dass sie unzählige Abhängigkeiten in ein Projekt bringen. 
Abhängigkeiten zu pflegen ist eines der Dinge die mir an der ganzen Softwareentwicklung am wenigsten Spaß machen. Dazu passiert es dann, wie bei gulp, dass ein Tool nicht mehr weiterentwickelt wird.
Bei webpack bin zusätzlich daran gescheitert, dass ich kein HTML prozessieren konnte. (Dazu werde ich auch noch einen Artikel schreiben)

Ein weiterer Nachteil ist, dass die Konfigurationsdatei von einem Projekt zu nächsten geschleppt wird. Dabei versucht dann der Entwickler, das Ganze Projekt noch besser zu parametrisieren als beim letzten Mal. 
Das Ergebnis sind riesige Dateien mit einer Unzahl an Variablen.
Ich habe Projekte gesehen, die über 1000 Zeilen in grunt-Dateien haben. Nur um ein bisschen Javscript und CSS zu bauen.

Die Alternative ist, wie beschrieben, die Dinge selbst in die Hand zu nehmen. Die größte Hürde hier ist, dass das Konzept ungewohnt ist. Man muss ein paar Fehler selbst einfangen und vielleicht mal etwas anpassen.

Aber der Gewinn liegt meiner Meinung Hand:
1. Wir lernen mehr über unsere Tools (esbuild, dart-sass, etc.)
2. Wir lernen mehr über Javascript
3. Das Buildtool wird wahrscheinlich schneller sein
4. Wir haben weniger Abhängigkeiten

Eigentlich bin ich großer Fan fertiger Software und ein Gegner davon, existierende Dinge neu zu erfinden: Ich muss keinen neuen Slider programmieren.
Aber Taskrunner sind Software die eine Arbeit verrichten die man genauso gut in einem bash-script laufen lassen kann. D. h. sie sind schon eine Neuerfindung von etwas existierendem .
Mit npm haben wir ein tolles Package-Verwaltungssystem das uns den ganzen Support bietet.
Sollte die Konfiguration von sass oder esbuild ein bisschen komplizierter werden, kann das in eigenen Datei abgelegt werden.

Kommentare

Keine Kommentare

Kommentar schreiben

* Diese Felder sind erforderlich