Die meisten kennen die bisherigen Diskussionen rund um Nx: Integrated vs. Package-based. Seit Version 15.3 steht euch im Rahmen des Nx Setups eine weitere Option zur Verfügung: die Standalone-Variante. Ein Standalone-Projekt in Nx bedeutet, dass es kein Monorepo ist, sondern eine einzelne Anwendung auf der obersten Ebene des Projekts hat. Dieses Setup ähnelt dem, was die Angular CLI bietet, weist jedoch einige relevante Unterschiede auf. Nx setzt bei Unit-Tests auf Jest, während Angular weiterhin Jasmine und Karma als Abhängigkeiten installiert. Bei den Integrationstests bietet Nx zusätzlich die Möglichkeit, Playwright zu nutzen, eine Option, die Angular 18 noch nicht standardmäßig unterstützt.
Warum sollte man nun die Standalone-Variante von Nx statt der Angular CLI nutzen? Der Hauptgrund ist, dass die Monorepo-Philosophie weiterhin beibehalten wird. Dies bedeutet, dass eine Ebene für Bibliotheken vorhanden ist, was eine modularere und skalierbarere Struktur ermöglicht. Das Besondere ist, dass ein Standalone-Projekt in Nx später problemlos in ein Monorepo erweitert werden kann. Dies kann sich bei einer reinen Angular-CLI-Struktur als schwierig erweisen.
Zusätzlich bietet die Standalone-Variante von Nx weitere Vorteile:
- Fortschrittliches Caching und Build-Optimierungen: Nx nutzt effiziente Caching-Mechanismen, die die Build-Zeiten erheblich verkürzen können.
- Parallele Ausführung von Tasks: Aufgaben wie Linting, Testing und Building können parallel ausgeführt werden, was die Entwicklungsgeschwindigkeit erhöht.
- Einfache Importe durch TypeScript Path Mapping: Dies erleichtert das Arbeiten mit Modulen und Bibliotheken.
- ….
Darüber hinaus bringt Nx viele weitere Vorteile mit sich, die es zu einem leistungsstarken Werkzeug für die Entwicklung von Angular-Anwendungen machen.
Insgesamt macht die Standalone-Variante von Nx die Entwicklung von Angular-Anwendungen nicht nur effizienter, sondern bietet auch zahlreiche Erweiterungsmöglichkeiten, die in der traditionellen Angular CLI nicht standardmäßig verfügbar sind. Aus diesem Grund ist es eine sehr gute Alternative für doubleSlash bei grundlegenden Architekturentscheidungen.
