Barista: Verschieben Sie benutzerdefinierte Builder in Nx-Plugins

Erstellt am 19. Feb. 2020  ·  8Kommentare  ·  Quelle: dynatrace-oss/barista

Featureanfrage

Verschieben Sie unsere benutzerdefinierten Builder auf Nx-Plugins:

https://github.com/nrwl/nx/commit/fe98e29#diff -9e66bea35c8c76309609c9218bc259c4R30

Plugins sind der offizielle Weg, wie wir mit unseren Buildern und dem gesamten Tooling umgehen sollten.

P2 feature no-issue-activity

Hilfreichster Kommentar

Alles klar. Wie ich die Erklärung verstanden habe, die mir @ffriedl89 gegeben hat:

  • Wir mussten alle unsere Tools in den libs-Ordner für #570 verschieben, da nx in ihrer Boundary-Linting-Regel hartcodierte Pfade von apps und libs
  • Da wir jetzt Tools in Libs verschoben haben, schlagen andere Linting-Regeln von nx fehl, weil sie zusätzliche Dateien in ihrem Bibliotheksstamm nicht zulassen (zB Dockerfile, ect. _Dateien, von denen wir in einigen Tool-Gelegenheiten abhängen_)
  • Nx bietet mit der Version 9 eine neue Lösung für diese an, da sie offenbar bemerkt haben, dass zusätzliches Tooling benötigt wird. Und ihr Weg, dies zu tun, besteht darin, die Werkzeuge (die nicht als Bibliothek betrachtet werden sollten) in einen Plugin-Ordner hinzuzufügen, in dem Linting weniger streng ist.

Alle 8 Kommentare

Ich frage mich, warum wir das tun müssen. Gibt es einen Schmerz, den wir mit diesem lösen? Soweit ich sehen kann, funktioniert das Werkzeug, wie wir es haben, jetzt. Welche Vorteile haben wir, wenn wir all unsere Tools in nrwl-Plugins umschreiben?

nicht umschreiben – es ist eher wie es in den nx-Workspace integriert ist. Es sollte eher eine Konvertierungsbibliothek in ein Plugin sein. Dann können wir die "hackige" Art und Weise loswerden, wie unsere eigenen Bauherren gebaut werden.
mit einem tsc --outdir /node_modules/dynatrace/barista-builders zum Beispiel

Wir sollten uns immer an die Richtlinien von nx halten, da es sich um eine eigenwillige Ordnerstruktur handelt und ansonsten die Tools nicht wie erwartet funktionieren

Bitte korrigieren Sie mich, wenn ich hier falsch liege, aber derzeit funktioniert das Tool wie erwartet, nicht wahr?

nicht. Wir stoßen auf Probleme mit Dateien, die nicht fusseln und aus Tools importiert werden, wo wir unser Abhängigkeitsdiagramm zerquetschen. Unsere Tools sind keine Bibliotheken aber keine Tools im Sinne von nrwl/nx. Sie sind Plugins, also sollten wir sie als eins behandeln. Dies sollte nach @ffriedl89- Workspace-Refactorings

Alles klar. Wie ich die Erklärung verstanden habe, die mir @ffriedl89 gegeben hat:

  • Wir mussten alle unsere Tools in den libs-Ordner für #570 verschieben, da nx in ihrer Boundary-Linting-Regel hartcodierte Pfade von apps und libs
  • Da wir jetzt Tools in Libs verschoben haben, schlagen andere Linting-Regeln von nx fehl, weil sie zusätzliche Dateien in ihrem Bibliotheksstamm nicht zulassen (zB Dockerfile, ect. _Dateien, von denen wir in einigen Tool-Gelegenheiten abhängen_)
  • Nx bietet mit der Version 9 eine neue Lösung für diese an, da sie offenbar bemerkt haben, dass zusätzliches Tooling benötigt wird. Und ihr Weg, dies zu tun, besteht darin, die Werkzeuge (die nicht als Bibliothek betrachtet werden sollten) in einen Plugin-Ordner hinzuzufügen, in dem Linting weniger streng ist.

@tomheller perfekte Zusammenfassung: D

Dieses Problem ist veraltet, da es seit 30 Tagen ohne Aktivität geöffnet war. Entferne veraltetes Label oder Kommentar oder dies wird in 5 Tagen geschlossen

Dieses Problem ist veraltet, da es seit 90 Tagen ohne Aktivität geöffnet war. Entferne veraltetes Label oder Kommentar oder dies wird in 5 Tagen geschlossen

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen