Nx

Obwohl es eine nette Interpretation der chaotischen Javascript-Toolchain ist, sind die Standardeinstellungen für das einfachste TypeScript-Projekt chaotisch und funktionieren nicht. Ich habe Stunden damit verbracht, ziemlich einfache Dinge zu haben; Da zum Beispiel Sourcemaps aktiviert sind, schließen Sie bitte die Quellen ein ... und transpilieren Sie nicht in einen „src“-Ordner. Andernfalls werden die Importe beim Hinzufügen von Quellen chaotisch und ich versuche, die ts-Datei zu importieren. Und warum transpilieren Sie alles in einen externen „dist“-Ordner? Dadurch sind alle Sourcemap-Referenzen falsch (""../../../../packages/etc/etc/file.ts") und nichts funktioniert. Nx umhüllt und verbirgt viele Details, aber die Umhüllung verbirgt und blockiert oft nützliche Dinge; Ich habe meiner Jest-Konfiguration zwei völlig gültige Konfigurationseinstellungen hinzugefügt (nämlich maxWorkers und testSequencer), und es funktioniert, wenn ich nur „cd package/name; npx jest“ ausführe. Der Nx-Wrapper für Jest erkennt sie jedoch nicht und wendet sie daher nicht an, sodass Tests nicht funktionieren. Dabei enthält jedes Paket ACHT Dateien im Stammverzeichnis, die gemeinsame package.json und README.md (ja, diese könnte man löschen), dann drei tsconfig-JSON-Dateien, eine Jest-Konfiguration, eine .eslint.json ... und da diese nicht ausreichen, fügt Nx seine eigene project.json-Datei hinzu. Diese Dateien werden generiert, sodass sie in jedem Ordner immer wieder dasselbe wiederholen. Wenn also etwas geändert werden muss, muss es an allen Stellen geändert werden. Die Datei „project.json“ war besonders langweilig lang (standardmäßig 47 Zeilen), aber sie änderte nur die Pfade (konnte sie nicht einfach „cwd“ sein und relative Pfade verwenden?). Nach tagelanger Verwendung fand ich dann eine Seite, auf der erklärt wurde, dass der Großteil des Inhalts von „project.json“ in nx.json im Stammordner festgelegt werden konnte, und die es mir ermöglichte, über 500 Zeilen nutzloser Wiederholungen zu löschen. Warum gibt es also kein automatisches Gerüst? Macht das Ding das schon? Warum musste ich es herausfinden und es dann manuell tun? Angesichts des Hypes, den dieses Projekt überall auslöst, habe ich viel, viel mehr erwartet. Am Ende habe ich alle generierten Dateien geändert und bereinigt, sodass ich den Generierungsteil nicht mehr verwenden kann. Ich kann bei vielen meiner Pakete keine Tests durchführen, sodass es nicht viel mehr ist als ein for-cycle-Ausführungslauf von npm in jedem Ordner. Vielleicht gibt es verschiedene Anwendungsfälle, in denen es hervorragend funktioniert, vielleicht weil ich jahrelang Java mit Maven verwendet habe. Ich bin einfach zu sehr daran gewöhnt, ein Projekt mit Dutzenden von Modulen in ein paar Stunden einzurichten. Ich versuche nur, ein Monorepo mit einer Bibliothek von 10 Paketen darin zu haben.

Nx ist das Herzstück jedes Webentwicklungsprojekts, an dem ich arbeite. Wir legen nicht jedes Projekt im Unternehmen im selben Repo ab, sondern gruppieren verwandte Projekte. Aber selbst wenn es nur eine einzige Anwendung in einem Repo gibt, bietet Nx mit Upgrades, Abhängigkeitsmanagement für mehrere Projekte, Code-Gerüst und mehr einen großen Mehrwert.

Sehr einfach zu bedienen, hatte viele Plugins, die häufig aktualisiert werden und bei der Pflege eines Repos helfen. Sie können Plugins nach Belieben verwenden, um einen Teil Ihres Workflows zu verbessern, wenn Sie Plugins nicht vollständig nutzen können

Vereinfacht die Entwicklererfahrung enorm. Einfach zu verwenden und zu erweitern für alle Arten von Softwareprojekten. Nx ist mein täglicher Treiber für die Softwareentwicklung (insbesondere die Angular-Entwicklung).

Vereinfacht die Entwicklererfahrung, verbessert die Build-Geschwindigkeit und bietet großartige Tools. Alle meine Projekte beginnen mit Nx.

Die Kernfunktionen von Nx sind großartig, aber das kann ich nicht über die Cloud sagen