2016-06-21 12 views
0

Das mag ein bisschen kompliziert sein, aber ich werde mein Bestes geben. Ich habe eine Reihe von API-Modulen, die ich mit Browserify verwende, und einige von ihnen rufen auch andere Module auf. Sie sind ziemlich miteinander verwoben, was die Aktualisierung erschweren wird.Aktualisieren Sie ein einzelnes CommonJS-Modul, ohne jedes einzelne benötigte Modul zu berühren.

Zum Beispiel habe ich fünf Module: A, B, C, D und E. A wird von B und C benötigt, und B wird von C, D und E benötigt. Wenn ich machen muss einige Updates zu A, die Änderungen brechen, ich könnte es versionieren, aber dann muss ich die require-Anweisungen in B und C aktualisieren. Und da B jetzt eine andere Version von A verwendet, muss ich auch Version B verwenden, was bedeutet Ändern der require-Anweisungen in C, D und E. Also eine einzige Änderung in einem Modul bedeutet, dass ich alles andere umkehren muss.

Ich sollte beachten, dass der Hauptgrund dafür ist, dass ich alte Versionen behalten muss. Dies sind kleine Microsites, und eine Site könnte mit A - E gebaut werden und die nächste könnte mit A '- E' gebaut werden, aber ich muss trotzdem in der Lage sein, beides unabhängig voneinander zu erstellen. Auch wenn sich die Änderung von A 'nicht auf die API auswirkt, möchte ich nicht jedes einzelne Projekt, das jemals mit jeder einzelnen Dateiänderung erstellt wurde, erneut testen.

Ich dachte über eine separate pro-Projekt-Datei, die erforderlich sein könnte in und es erfordert dann alle versionierten Module für dieses Projekt, aber das ist eine zirkuläre Abhängigkeit.

Wenn es darauf ankommt, verwende ich Gulp und Browserify, um die endgültige JS-Datei zu erstellen.

Antwort

0

fand ich etwas, das den Trick tun würde: aliasify

ich meine Aussagen erfordern require('Api/ModuleA') und dann in der aliasify Config Modul A jedes Mal möchte ich Karte Api/ModuleA zu ./libs/Api/ModuleA-1.0 und es nimmt die Version I erfordert geändert

0

Ich verwendete einen Mechanismus ähnlich zu Java-Klassenpfaden. Ich habe einen benutzerdefinierten Modul-Resolver erstellt und separate Modul-Roots für separate Projekte verwendet. Ther war auch ein Ordner für gemeinsame Dateien. Der Modul-Resolver suchte zuerst nach dem Modul im Ordner des Projekts, und wenn es nicht gefunden wurde, suchte es im gemeinsamen Ordner. Auf diese Weise können Sie eine spezielle Implementierung von Modul A für ein bestimmtes Projekt bereitstellen. Nicht sicher, ob es in Ihrem Fall geeignet ist. Es ist etwas wie aliasify mit dem Unterschied, dass die Config durch Dateisystemordner anstelle von Konfigurationsdateien gesichert wird.

A ist ein Modul mit nur wenigen Abhängigkeiten und wird von vielen Modulen referenziert. Üblicherweise bezeichnen sie diese Art von Modul als "ausgereift". Diese ausgereiften Module sollten gut getestet sein, und die öffentliche Schnittstelle sollte sich nicht häufig ändern, da jedes abhängige Modul aktualisiert werden müsste. Sie könnten also versuchen, die Änderungen vorzunehmen, ohne die API zu unterbrechen, indem Sie möglicherweise ein neues Modul mit versioniertem Namen erstellen, und einen Wrapper des Moduls, der die alte API mit dem neuen Modul bereitstellt. Neue Komponenten könnten das neue Modul verwenden, alte Komponenten sind nicht betroffen.

Sie verwenden mehrere Zahlen, um eine Software aus einem bestimmten Grund zu versionieren. Im einfachsten Fall gibt es zwei Nummern: Haupt- und Nebenversionen. Minor-Version kann mit jeder Version ändern, Hauptversion erhöht sich, wenn die öffentliche API ändert. Alle Komponenten, die davon abhängen, müssen nur aktualisiert werden, wenn sich die Hauptversionen ändern. (Natürlich gibt es manchmal Fehler bei der Implementierung einer Nebenversion, die einige abhängige Komponenten unterbricht, aber das ist nicht der übliche Fall). Wenn Sie die öffentliche API von A ändern, müssen Sie auch B und C ändern, aber nicht die anderen. A würde eine größere Versionsänderung haben, B und C hätten eine Minderheit. Der Rest bleibt gleich. Dies erfordert einen komplizierteren Modulresolver, der die neuesten Module nach ihrer Hauptversion auflösen kann.Aber das macht npm sowieso.

+0

Ich habe über die Verwendung von Fallbacks nachgedacht, aber verschiedene Versionen sind nicht notwendigerweise * einen älteren abzulehnen. Der gleiche Grund, dass es nicht immer eine API-Änderung ist. Zum Beispiel muss ein Logger möglicherweise eine zusätzliche Protokollierungsquelle für einige Projekte hinzufügen, oder ein Datenmodul muss möglicherweise anders organisiert werden. Die externe API ändert sich nicht, und man ist nicht im Sinne der Versionierung "neuer" oder "besser", es ist einfach anders. – mherzig

+0

Ich denke, ein Protokollierungsmodul sollte nicht von seinen Quellen oder Zielen abhängen. Es könnte eine konfigurierbare Schnittstelle bereitstellen, und der Haupteintrag der Anwendung (der für jedes Projekt unterschiedlich ist) kann die Liste der Protokollierungsquellen oder -ziele bereitstellen. –