In dem vorerst letzten Teil der Serie geht es um die Verarbeitung von Typescript und React. Desweiteren zeige ich wie man Bibliotheken in dem globalen Kontext registriert (z.B. jQuery unter dem Namen $ und jQuery) und wie man Bibliotheken extern einbindet um sie von einem CDN zu laden.
Nachdem in den vorherigen Beiträgen eine grundlegende Struktur aufgebaut wurde, mit der man sein JavaScript-Projekt starten kann, wird dies noch um einige Funktionen erweitert, die die Entwicklung und die Fehlersuche erleichtern.
Dazu gehört der webpack-dev-server, der das Webprojekt zur Verfügung stellt und bei Änderung einer Quelldatei automatisch mittels Hot Module Replacement die Änderungen an den Browser überträgt.
Die Anzeige der Log-Ausgaben und der Status des Übersetzungsvorgangs wird im webpack-dashboard angezeigt.
Außerdem wird die webpack Loader-Konfiguration erweitert. Dazu gehört
- die Erstellung von Source-Maps
- die Verarbeitung von Sass: Syntactically Awesome Style Sheets,
- die automatische Vergabe von Vendor-Prefixen in den Stylesheets und die Minifizierung der finalen Stylesheet-Datei sowie
- die Optimierung von Bildern vor dem Produktionsdeployment.
Los geht's ...
Was haben wir bisher erreicht? Im ersten Teil haben wir mittels webpack unser erstes Applikationsbundle erzeugt und haben im zweiten Teil damit eine kleine Beispielanwendung erstellt.
Hierfür wurde eine Unterscheidung zwischen Entwicklung und Produktion eingeführt, um die Ausgabe für das Produktionsdeployment zu optimieren.
Im diesem Teil führen wir Babel ein, um andere Sprachvarianten in reines JavaScript zu übersetzen. Außerdem wird die Verarbeitung von weiteren Dateitypen behandelt, damit diese wie alle anderen Abhängigkeiten im Code als Modul importiert werden können. Da die webpack-Konfiguration sehr groß wird, wird diese in zwei Dateien aufgeteilt. Einen allgemeinen Teil, und einen speziellen Teil der die unterschiede der beiden Umgebungen (Produktion und Entwicklung) beinhaltet.
Das folgende Projekt basiert auf dem Beispiel aus Webpack from Nothing. Die Applikation liest ein mit Markdown Syntax gefülltes Textfeld ein und gibt den formatierten Text auf der gleichen Seite aus. Um die Webpack Konfiguration zu testen, wird später für jeden Dateityp eine Beispieldatei hinterlegt.
Nachdem das Projekt erstellt wurde, wird die webpack-Konfiguration aufgeteilt, um für Produktion und Entwicklung unterschiedliche Bundles zu erzeugen. Warum sollte man dies tun? Zum Beispiel um in der Produktion das entgültige Applikationsbundle zu minifizierien. Dies spart Bandbreite und schützt den Code etwas vor neugierigen Blicken.
Also lasst uns beginnen...
In diesem und den folgenden Beiträgen geht es um den Aufbau einer Vorlage für moderne Web-Anwendungen. Da drängt sich mir gleich die Frage auf, warum benötige ich eine eigene Vorlage? Es gibt doch für nahezu jedes aktuelle Framework bzw. jede aktuelle Bibliothek, ob React, Angular oder Vue, eine Vorlage bzw. ein Starter Kit.
Das ist richtig, aber ein Starter Kit hilft einem nicht zu verstehen, wie die im Entwicklungsprozess eingesetzten Tools interagieren, bzw. wo sie konfiguriert werden müssen. Kommt es dann zu einem Problem, welche unausweichlich kommen werden, darf man sich das benötigte Wissen anlernen, wenn man gerade keine Zeit dafür hat.
Deshalb lasst uns von vorne beginnen...