Seite 4: Setup des Beispielprojekts: Mission completed

Damit steht das Standard-Setup des Beispielprojekts. Abgesehen von der Nutzung von TypeScript ist damit allerdings noch nicht viel in Richtung Developer Experience unternommen – im nächsten Schritt ändert sich das. Hierzu gilt es zunächst, Prettier als automatischen Codeformatierer hinzuzufügen: yarn add -D prettier

Danach wird die Konfigurationsdatei für prettier mit dem namen .prettierrc und dem folgenden Inhalt erstellt:

{
    "semi": false,
    "tabWidth": 4,
    "proseWrap": "never",
    "printWidth": 100,
    "trailingComma": "none"
}

(Hinweis: Die angegebenen Werte sind die, mit denen der Autor persönlich gerne arbeitet – sie lassen sich nach Belieben ändern.)

Neben automatischer Formatierung ist auch automatisches Erkennen und Beheben von Fehlern und anderen Ungereimtheiten (Linting) wünschenswert, hierfür wird in diesem Beispielprojekt ESLint genutzt. ESLint und die nötigen Plug-ins werden mit der folgenden CLI-Eingabe installiert: yarn add -D eslint @typescript-eslint/parser @typescript-eslint/eslint-plugin.

Auch ESLint benötigt eine Konfigurationsdatei, in der die genutzten Regeln festzulegen sind. Sie trägt den Namen .eslintrc und hat den folgenden Inhalt:

{
    "root": true,
    "parser": "@typescript-eslint/parser",
    "plugins": ["@typescript-eslint"],
    "extends": [
        "eslint:recommended",
        "plugin:@typescript-eslint/eslint-recommended",
        "plugin:@typescript-eslint/recommended"
    ]
}

Neben der Regel erlaubt ESLint außerdem die Angabe, welche Dateien es in der Untersuchung nicht berücksichtigen soll. Hierfür wird eine Datei mit dem Namen .eslintignore benötigt. Der Inhalt lautet wie folgt:

build
node_modules

Die package.json ist nun um zwei Skripte zu erweitern, die jeweils den Codeformatierer und den Linter ausführen:

"scripts": {
  // ...
  "prettier": "prettier --write src/**/*.ts",
  "lint": "eslint -c .eslintrc --ext ts src",
  // ...
}

Um den Code nach den Regeln zu formatieren, die in der .prettierrc-Datei definiert sind, lässt sich der Aufruf yarn prettier nutzen. Außerdem kann man yarn lint aufrufen, um den Code manuell auf Fehler zu überprüfen. Der Aufruf yarn lint --fix versucht, alle Linting-Probleme im Code automatisch zu beheben. Alle Probleme, die danach weiterhin in der Ausgabe stehen, lassen sich nicht automatisch beheben – sie müssen von Hand behoben werden (s. Abb. 2).

Um die Developer Experience weiter zu verbessern, empfiehlt es sich, sowohl Prettier als auch ESLint direkt in die IDE zu integrieren. Das bedeutet, dass die IDE die geöffneten Dateien bei jedem Speichervorgang automatisch formatiert und auf Fehler überprüft und diese, wenn möglich, direkt behebt. Das erspart den Aufwand, häufig manuell yarn lint und yarn prettier aufrufen zu müssen.

Um Prettier und ESLint in Visual Studio Code zu konfigurieren, sind zunächst die Prettier- und ESLint- Erweiterungen zu installieren. Danach wird in dem Beispielprojekt ein neuer Ordner namens .vscode erstellt. Hierfür ist eine Datei mit dem Namen settings.json und dem folgenden Inhalt notwendig (s. auch Abb. 3):

{
    "[typescript]": {
        // Prettier
        "editor.defaultFormatter": "esbenp.prettier-vscode",
        "editor.formatOnSave": true,
        // ESLint
        "editor.codeActionsOnSave": {
            "source.fixAll.eslint": true
        }
    }
}

Um das Gleiche in WebStorm oder anderen IDEs von JetBrains zu konfigurieren, gibt es Anleitungen zu Prettier und zu ESLint.

Automatischer Reload erkennt Veränderungen an Quellcodedateien

Als Nächstes geht es um das Thema Auto Reload. Wie oben bereits erwähnt, erkennt ein Auto-Reload-Tool Veränderungen an Quellcodedateien, kompiliert daraufhin automatisch erneut den Code und startet die Anwendung neu.

Viele Scaffolding-Tools wie Create React App und Nest.js verfügen bereits über eine eingebaute Live-Reload-Funktion. Um ein solches Auto-Reload-Feature in unserer einfachen NodeJS- und Express-Anwendung einzurichten, kommt das Tool nodemon zum Einsatz. Es lässt sich über den folgenden Befehl installieren: yarn add -D nodemon

In Anlehnung an das Skript, das die Applikation startet, wird der Datei package.json nun ein weiteres start:watch-Skript hinzugefügt, das die Anwendung inklusive Live-Reload-Tool nodemon startet:

"scripts": {
  // ...
  "start:watch": "nodemon src/index.ts",
  // ...
}

nodemon erkennt automatisch, dass es in dem Projekt um TypeScript-Dateien geht und verwendet das zuvor installierte ts-node (anstelle des sonst üblichen node), um den Code auszuführen. Nun ist der Befehl yarn start:watch bereit, die Applikation zu starten. Im Gegensatz zu dem vorher definierten yarn start überwacht nodemon hier sämtliche Dateiänderungen und startet die Applikation automatisch neu, wie Abbildung 4 veranschaulicht.

Damit sind wir am Ende der Developer-Experience-Optimierung für das Beispielprojekt angekommen. Einige Scaffolding-CLIs, die bei Libraries wie React oder NestJS mit ausgeliefert werden, setzen viele der hier im Beispiel händisch durchgeführten Konfigurationen wie Linting und Live Reload automatisch mit auf. Das bedeutet, dass man beim Setup eines Projektes mit der Library Nest.JS und dem zugehörigen NestJS-CLI letztlich mit weniger Konfigurationsaufwand zum selben Ergebnis kommt, wie das Beispiel hoffentlich zeigen konnte. Falls also eine Library zum Einsatz kommen soll, die über ein eigenes Scaffolding-Tool in Form eines Command-Line Interfaces verfügt, empfiehlt sich alternativ durchaus die Nutzung dieses CLI.