Frontend 1x1 für Backend Devs

Für Entwickler:Innen, die nicht im Frontend aktiv sind, sich aber zumindest einen Überblick dort verschaffen wollen.

In diesem Artikel möchte ich einen ersten Überblick über ein typisches Frontend-Projekt geben und dabei helfen, sich dort etwas zu orientieren. Auch wenn man seinen Schwerpunkt in anderen Bereichen der Anwendung sieht, kommt man hin und wieder nicht am Frontend vorbei. Glücklicherweise gibt es hier ein paar Standards, an denen man sich orientieren kann.

Wir sehen uns also an wie man eine bestehende Frontend-Anwendung lokal einrichtet und dann auch starten, testen oder bauen kann. Bei allen Schritten besteht die Gefahr, dass es natürlich gerade im jeweiligen Projekt etwas anders gelöst wurde. In vielen Fällen kann man das sicher diskutieren, aber wir gehen mal davon aus, dass die Entwickler sich dabei was gedacht haben. Sollte Euer Projekt also davon abweichen, was ich hier schreibe, müsst ihr wohl mal bei den Kolleg:Innen nachfragen.

Startpunkt: package.json

Build und Dependencies werden in den meisten Projekten über die package.json konfiguriert, die im Root des (Frontend-) Projekts liegen sollte. Diese enthält einige Meta-Informationen zum Projekt wie einen Namen, manchmal eine Version, benötigte Dependencies und Skripte, mit denen man das Projekt bauen, starten und vielleicht auch testen kann. Oft enthält sie auch die Konfiguration für verwendetes Tooling, dies kann aber auch in einer eigenen Datei liegen.

Ein guter Start ist hier zunächst alle Abhängigkeiten zu installieren und da kann es auch direkt spannender werden.

Die richtige Node Version

Grundsätzlich sollte man nun sicherstellen, dass man die richtige Node Version installiert hat. Normalerweise ist diese Version im Projekt definiert, etwa in einer Dokumentation, einer Readme, der package.json oder einer eigenen Konfigurationsdatei (.nvmrc). Ich verwalte meine Node-Versionen schon seit mehreren Jahren mit nvm und bin damit auch sehr zufrieden. Sollte im Projekt eine .nvmrc liegen, kann mit nvm use die richtige Node Version ausgewählt und installiert werden. Ansonsten würde ich die aktuelle LTS Version nutzen. Die nvm Dokumentation ist hervorragend und beschreibt alle hierfür notwendigen Schritte.

Bei den meisten Frontend-Projekten ist die Nutzung der richtigen Node-Version nicht zwingend erforderlich „um nur mal alles zu starten oder testen“, man sollte eben danach keine Änderungen am Code committen, die beispielsweise bei der Installation der Dependencies aufkommen könnten. Das Gleiche gilt auch für den nächsten Schritt: dem Package Manager.

Der richtige Package Manager

Wie schon bei der Node Version scheiden sich hier die Geister und in diesem Artikel möchte ich auch nicht zu tief auf das Thema Package Manager eingehen. Mit Node wird npm ausgeliefert (für mich der Hauptgrund die richtige Node Version zu nutzen) und in vielen Projekten reicht das auch um „nur mal alles zu starten“. Wie auch bei der Node Version sollte dokumentiert sein, welches Tool im Projekt eingesetzt wird. Meistens ist dies entweder npm oder yarn, es gibt aber auch viele andere Tools hier.

Wenn das Projekt neben der package.json eine package-lock.json hat, spricht dies für die Nutzung von npm. Sollte stattdessen eine yarn.lock dort liegen, wird wohl yarn eingesetzt. Natürlich gibt es auch Projekte, die beide Dateien beinhalten oder keine von beiden. In beiden Fällen würde ich das kritisch hinterfragen, das kann aber auch ein Wespennest im Projekt sein.

Die Fallback-Lösung meiner Wahl wäre jetzt wieder der „Standard“ npm wobei ich auch hier aufpassen würde, was im Repository passiert. Ich würde auch hier, wenn ich fertig bin, alle Änderungen rückgängig machen und den node_modules Ordner wieder löschen.

Dependencies installieren

Dependencies lassen sich mit npm über npm install und mit yarn über yarn installieren. Beides sollte im Ordner ausgeführt werden, in dem die package.json liegt. Danach sollte im gleichen Ordner ein node_modules Ordner angelegt werden, der (hoffentlich) auch in der .gitignore steht.

An dieser Stelle kann es zu einem Fehler kommen, wenn die verwendeten Dependencies in einem eigenen Repository liegen und npm konfiguriert werden muss. Dies sollte auch in einer normalen Projektdokumentation zu finden sein und bedeutet meistens nur, dass man in einem der Elternverzeichnisse des Frontend-Projekts noch eine .npmrc anlegen muss.

Nun kann man das Projekt starten, bauen und testen, indem man die passenden Skripte ausführt.

Projekte starten, testen und bauen

Wir kommen zurück zur package.json in der es einen Block scripts geben sollte. Diese key-value-Paare beschreiben die Skripte, die im Projekt unterstützt werden (das ist der jeweilige key) und was diese tun (das jeweilige value). Auch wenn ich jetzt in Beispielen npm nehme, kann man hier auch den jeweils in Verwendung befindlichen Package Manager analog nutzen:

Um jetzt eines der Skripte zu starten, führt man im Terminal npm run <key> aus. Nehmen wir an unsere package.json enthält nur ein Skript, um Tests auszuführen und nutzt hierfür jest:

"scripts": {
   "test": "jest"
}

Mit einem npm run test kann ich dann dieses Skript ausführen. Die im Projekt installierten Tools (die wir schon installiert haben) werden durch npm an den PATH angehangen und können so einfach gestartet werden.

Ich würde hier jetzt Skripte erwarten, die das Projekt starten und bauen können. Bei den meisten Projekten, die ich kenne, sind die Namen, da recht sprechend, ansonsten empfiehlt sich auch hier ein Blick auf die Dokumentation oder der Kaffee mit den Kolleg:Innen.

Ich hoffe, dieser kleine Guide hilft Euch bei Eurer Arbeit. Was würde Euch noch interessieren? Wo hängt ihr bei der Arbeit mit den Frontend-Kolleg:Innen? Schreibt mir gerne auf Mastodon.