CLI-Tool

Hier wird erläutert, wie das CLI-Tool entwickelt wurde und auf welchen Konzepten es basiert. Unser Schwerpunkt lag darauf, das Tool benutzerfreundlich zu gestalten.

Für die Entwicklung des Tools haben wir und verwendet. Wir haben uns für diese Sprachen entschieden, da wir sie bereits beherrschten und auch andere CLI-Tools damit erstellt werden. Zudem bieten diese Ökosysteme eine hervorragende Unterstützung. Wir wollten nicht alles von Grund auf selbst erarbeiten, da dies sehr viel Zeit in Anspruch genommen hätte; stattdessen wollten wir diese Zeit lieber für die eigentliche Entwicklung des Tools nutzen.

Abhängigkeiten

In diesem Abschnitt stellen wir die Abhängigkeiten (Dependencies) vor, die wir für den Bau unseres CLI-Tools verwendet haben.

Commander

Für die Erstellung des CLI-Tools haben wir die Bibliothek „Commander“ verwendet. Sie bietet alle Funktionen, die wir benötigen: Wir können Befehle konfigurieren, TypeScript nutzen und vieles mehr.

Inquirer

Für eine interaktive Befehlszeilenschnittstelle (CLI) haben wir „Inquirer“ eingesetzt. So haben wir beispielsweise eine Hilfsfunktion für interaktive Befehle implementiert, die greift, wenn ein Benutzer einen Befehl falsch schreibt.

Wenn Sie sich zum Beispiel bei „check“ vertippen und stattdessen „ceck“ eingeben:

Chalk

„Chalk“ ist eine weit verbreitete Bibliothek für die farbliche Gestaltung der Terminal-Ausgabe. Sie ist einfach zu handhaben. Im obigen Bild haben wir Chalk verwendet, um den falsch geschriebenen Befehl gelb hervorzuheben.

Die Bibliothek lässt sich nahtlos mit anderen Tools wie Inquirer kombinieren und ist benutzerfreundlich. Chalk kann buchstäblich an jeder Stelle des CLI-Tools eingesetzt werden.

Ora

„ora“ ist eine Bibliothek für Ladeanzeigen und Spinner. Sie verleiht der CLI eine besondere Note und trägt zudem zur Verbesserung der Benutzererfahrung bei.

Figlet

Wir haben „Figlet“ für das NDM-Banner im ndm info-Befehl verwendet. Es ist wesentlich einfacher, diese Bibliothek zu nutzen, als eine solche Lösung selbst zu implementieren.

ConfigStore

„configstore“ ist eine Bibliothek für Konfigurationszwecke. Wir setzen sie ein, um die Konfiguration für die Serveradresse zu verwalten und zu speichern.

Ordnerstruktur

Für das CLI-Tool verwenden wir eine leicht verständliche Ordnerstruktur. Die folgende Grafik zeigt die Speicherorte der wichtigsten Dateien:

.github/
src/
├─ commands/
│   ├─ check.ts
│   ├─ info.ts
│   ├─ analyze.ts
│   └─ ...
├─ utils/
│   ├─ banner.ts
│   ├─ config.ts
│   └─ checks/
│      ├─ calcHealthScore.ts
│      ├─ calculateRiskScore.ts
│      └─ ...
└─ index.ts
test/
├─ example.test.ts
└─ utils/
├─ checks.test.ts
├─ checks2.test.ts
└─ ...

Alle Befehle sind im Ordner commands abgelegt. Zur besseren Organisation haben wir sie in die Datei index.ts importiert.

import { Command } from "commander";
import { infoCommand } from "./commands/info";
...
async function main() {
const program = new Command(); 

program
.name("ndm")
.description(
"NDM CLI Tool – Node Dependency Monitor -understand how packages work.",
)
.version("0.1.0"); 

// Registrierung der Befehle:
program.addCommand(infoCommand); // Das Hinzufügen eines Befehls ist sehr einfach
...
}
main();

Die umfangreicheren Unterfunktionen der eigentlichen Befehle haben wir im Ordner utils gespeichert. Es gibt zum Beispiel eine Datei namens askForPackageName.ts, da der Paketname sowohl beim Befehl check als auch bei analyze abgefragt wird.

UX

Für eine gute User Experience setzen wir Farben ein, damit der Text leicht lesbar ist und die wichtigsten Informationen schnell erfasst werden können. Zudem verwenden wir Balken zur Darstellung der Health- und Risk-Scores.

...
Overall Risk Score:
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ 0/100  // in der CLI rot dargestellt
...
Overall Health Score:
██████████████████████████░░░░ 85/100 // in der CLI grün dargestellt

Wir verwenden Ladeanzeigen, um dem Nutzer zu signalisieren, dass NDM gerade arbeitet. Der Befehl check informiert den Nutzer zudem darüber, welche Aufgabe NDM während des Ladevorgangs gerade ausführt.

Development Tools

Um die NDM-Codebasis sauber, wartbar und konsistent zu halten und dies über alle Beitragenden hinweg sicherzustellen, setzen wir mehrere Entwicklungstools ein, die automatisch Coding-Standards und Qualitätskontrollen durchsetzen.

wichtig

Zusätzlich werden GitHub Actions verwendet, um jeden Pull-Request, der sich auf den main branch bezieht, zu validieren. So wird sichergestellt, dass alle Codeänderungen den Formatierungs- und Qualitätsanforderungen des Projekts entsprechen, bevor sie eingecheckt werden können.

Linter

Oxlint wird als unser Linter genutzt. Es ist Teil des Oxc-Ökosystems und wurde aufgrund seiner herausragenden Leistung und der modernen TypeScript-Unterstützung ausgewählt. Da Oxlint in Rust geschrieben ist, ist es deutlich schneller als viele traditionelle JavaScript-basierte Linter, während es gleichzeitig hochwertige Diagnosen liefert.

Ein Linter ist ein hilfreiches Tool, das dabei unterstützt, potenzielle Probleme bereits vor der Produktion zu erkennen.

• Mögliche Programmierfehler
• Code-Mustern, die auf Fehlverhalten oder Fehleranfälligkeit hinweisen
• Variablen und Importe, die nicht genutzt werden.
• Verstöße gegen die Projekt-Coding-Standards
• Probleme mit der Wartbarkeit und Lesbarkeit

Jeder Pull-Request wird automatisch mit Oxlint über GitHub Actions überprüft. Ein Pull Request kann nicht verarbeitet werden, wenn Linting-Fehler erkannt werden.

Entwickler können den Linter mit folgendem Befehl ausführen:

pnpm lint

Formatter

Prettier wird als unser Codeformatter verwendet. Es ist eines der am weitesten verbreiteten Formatierungstools im JavaScript- und TypeScript-Ökosystem und sorgt für einen konsistenten Code-Stil mit fast keiner Konfiguration.

Die Hauptvorteile der Verwendung von Prettier sind:

• Verbesserte Code-Lesbarkeit
• Konsistente Formatierung im gesamten Projekt
• Verbesserte Code-Lesbarkeit
• Reduzierte Diskussionen über den Code-Stil
• Einfachere Code Bewertungen
• Bessere Zusammenarbeit zwischen den Beiträgern

Jeder Pull Request wird automatisch mittels GitHub Actions mit Prettier überprüft. Ein Pull Request kann nicht zusammengeführt werden, wenn Formatierungsfehler festgestellt werden.

Entwickler können das gesamte Projekt lokal mit folgendem Befehl formatieren:

pnpm format