Ich habe eine sehr einfache Arbeitsweise:
%Vor%Denken Sie daran, dass A und B auf verschiedenen Rechnern sind (denken Sie an Jenkins-Cluster!).
In zwei Versionen enden die Versionen mit "-SNAPSHOT" und werden bei jedem Build aktualisiert (A). Natürlich sollten die abhängigen Bibliotheken (B, ...) immer die neueste Version aus der Registrierung verwenden. Problem ist, NPM wird nicht die gleiche Version holen.
%Vor%Das wäre okay, weil wir einen lokalen npm-Proxy haben: "~ / .npmrc":
%Vor%Aber das funktioniert nicht ! Nur das Entfernen des Knotens node_modules funktioniert. Dies ist keine brauchbare Lösung, da der Entwickler "rm -rf node_modules & amp; & amp; npm install" nicht verwenden sollte.
Mit maven funktioniert dieses Setup, weil wir die Option "-U" verwenden. Dies zwingt Maven zu prüfen, ob eine aktualisierte SNAPSHOT-Version verfügbar ist. NPM versteht das Konzept von SNAPSHOT nicht, aber sollte zumindest jedes Mal die Registry fragen.
npm Version 2.12.0
Private Registrierung: Sonatype Nexus ™ 2.10.0-02
Idee 1
Sie können dieses Verhalten nachahmen, wenn Sie den Vorabversionsteil von SemVer "missbrauchen". Ich habe die folgende Strategie erfolgreich verwendet:
Veröffentlichen Sie Ihre Module mit -SNAPSHOT , fügen Sie jedoch bei jeder Veröffentlichung eine inkrementierte Zahl hinzu ( -SNAPSHOT.# oder -SNAPSHOT-# ).
Zum Beispiel: "x.x.x-SNAPSHOT.1" die erste Veröffentlichung, dann "x.x.x-SNAPSHOT.2" die zweite Veröffentlichung und so weiter.
Stellen Sie sicher, dass Sie ein konsistentes Muster verwenden. Wenn Sie beispielsweise Punkte verwenden, mit Punkten kleben oder Bindestriche verwenden, bleiben Sie mit Bindestrichen.
Für abhängige Module müssen Sie nur Ihre Version als
deklarieren %Vor%und NPM ruft die neueste Version ab.
All dies funktioniert aus zwei Gründen
1.0.0-SNAPSHOT < 1.0.0-SNAPSHOT.1 < 1.0.0-SNAPSHOT.2 < 1.0.0-SNAPSHOT.3 ... Vorbehalt : Dies funktioniert nur für Patch-Versionen. Technisch gesehen ist 1.2.x-SNAPSHOT größer als 1.1.x-SNAPSHOT, jedoch berücksichtigt SemVer dies nicht, wenn Vorversionen verwendet werden.
Aus der Dokumentation:
Wenn eine Version ein Prerelease-Tag hat (z. B. 1.2.3-alpha.3), dann ist dies der Fall darf Comparator Sets nur dann erfüllen, wenn mindestens eins vorhanden ist Komparator mit dem gleichen [Major, Minor, Patch] Tupel hat auch eine Prerelease-Tag.
Zum Beispiel könnte der Bereich & gt; 1.2.3-alpha.3 mit dem übereinstimmen Version 1.2.3-alpha.7, würde aber nicht mit 3.4.5-alpha.9 zufrieden sein, obwohl 3.4.5-alpha.9 ist technisch "größer als" 1.2.3-alpha.3 gemäß den Sortierungsregeln von SemVer. Der Versionsbereich akzeptiert nur Prerelease-Tags in der 1.2.3-Version. Die Version 3.4.5 würde genügen der Bereich, weil es kein Vorab-Flag hat, und 3.4.5 ist größer als 1.2.3-alpha.7.
Idee 2 Auch dies ist ein weiterer "Hack". Wenn es Ihnen gelingt, den Patch-Teil von SemVer zu verlieren, können Sie Ihre Versionen als
veröffentlichen x.x.<unix epoch ms> .
Die Unix-Epoche nimmt ständig zu (mindestens bis 2038 für 32 Bit) und bei jeder Veröffentlichung veröffentlichen Sie immer eine größere Version.