Organisieren von Abhängigkeiten von package.json in universellen/isomorphen Anwendungen

Question

Mit React und anderen Frameworks ist es jetzt üblich, npm und package.json zu verwenden, um die Bibliotheken zu installieren, die Sie am Frontend verwenden. Wenn Sie eine universelle/isomorphe App entwickeln, führt dies zu dem Problem, dass die Abhängigkeiten für das Frontend und Backend in derselben Datei gespeichert sind, wodurch eine umfangreiche Abhängigkeitsliste erstellt wird.

Wenn Sie npm --save/- save-dev benutzen, werden beide Arten von Abhängigkeiten (Frontend, Backend) gemischt und es ist schwierig zu wissen, ohne eins nach dem anderen zu gehen, welches wo benutzt wird.

Abgesehen von der manuellen Sortierung und Verwaltung der Abhängigkeitsliste gibt es eine Möglichkeit, die Liste sauber zu halten? Welche Strategien haben Sie, um Abhängigkeitslisten zu verwalten?

Answer 1

In einer universellen/isomorphen App werden Sie wahrscheinlich nur wenige Abhängigkeiten haben, die rein Frontend oder rein Backend sind; Die meisten Abhängigkeiten sind geteilt.

Eine Option, die mir in den Sinn kommt, ist mehr als ein package.json zu verwenden:

• eine für isomorph Abhängigkeiten (reagieren, redux, etc.) und Utility-Abhängigkeiten wie das Build-System (babel, webpack, etc .), Aufgabenläufer (Schluck, Cross-env), Testen (Karma) und so weiter;
• eine für reine Frontend-Abhängigkeiten;
• eine für reine Backend-Abhängigkeiten.

Ich habe nicht die Struktur selbst, und ich bin mir nicht sicher verwendet, dass es besser verwaltbar sein, dass ein einzelner package.json, weil Sie mehr Dinge verwalten werden müssen (und wenn Sie npm-shrinkwrap hinzufügen das sind doppelt so viele Dateien).

Answer 2

Ich stimme stark mit sompylasar Antwort und möchte ein wenig weiter darauf erweitern. Ich denke wirklich, dass zwei verschiedene package.json-Dateien der einzige Weg sind, dies zu tun.

Denken Sie an Ihr Frontend und Ihr Backend als zwei verschiedene Anwendungen. Auch in zwei sehr unterschiedlichen Umgebungen werden die Anforderungen an die Verpackung und die Baukette unterschiedlich sein.

Der ganze Punkt von npm ist isolierte Abhängigkeiten pro Paket haben. Sie gehen dagegen, indem Sie Ihre Abhängigkeitsliste mit zwei völlig unabhängigen Anwendungen (Frontend und Backend) teilen.

Stellen Sie sich vor, Sie würden neue Frontend-Entwickler anheuern und einige Frontend-Pakete aufrüsten wollen, jetzt müssen sie weitermachen und herausfinden, wie sie das Backend ausführen und auch testen, weil sie dort etwas kaputt machen könnten.

Es könnte sein, dass es am Anfang ein bisschen mühsamer ist, zwei package.json Dateien zu verwalten, aber diese Art der Isolierung hält Ihre App gesund, wenn sie wächst.

Als solche würde ich eine Struktur empfehlen, wo Sie zwei Geschwisterordner mit jeweils eigenen package.json haben. Genau wie Sie das strukturieren wollen, ist Ihnen überlassen.

Wenn Sie Kerngeschäftslogik haben, die Sie zwischen Frontend und Backend teilen möchten, dann können Sie das natürlich in einem separaten npm-Paket ablegen, auf das Sie dann in Ihrem Backend- und Frontend-Paket als Abhängigkeit verweisen können. Sie können npm link verwenden, um gleichzeitig in Front- und Backend gegen die gleiche Version zu entwickeln.