Zwei Versionen desselben npm-Pakets in der Knotenanwendung

Question

Ich arbeite an einem CLI-Tool in NodeJS, das ein anderes von uns entwickeltes NodeJs-Paket verwendet, nämlich ein SDK.

Die Sache ist, wir haben nur eine V2-Version des SDK veröffentlicht, und wir wollen die CLI-Benutzer eine Legacy-Modus bieten, so dass sie entweder die erste oder die zweite Version unseres SDK, wie so verwenden:

$ cli do-stuff 
#execute sdk v2 

Oder

$ LEGACY_MODE='on' cli do-stuff 
#execute sdk v1 

Mein Problem ist, dass ich keine saubere Art und Weise zu verwenden, um zwei Versionen derselben Abhängigkeit in meinem CLI gefunden haben. Ich habe versucht, npm-install-version Paket zu verwenden. Es funktioniert gut in meiner lokalen Umgebung, aber nach dem Veröffentlichen meiner CLI und tun npm install -g my-cli, funktioniert es nicht mehr, weil es einen Ordner node_modules in dem aktuellen Ordner anstelle des Ordners /usr/local/lib/node_modules/my-cli erstellt. Ich habe auch versucht multidep, und ich habe irgendwie das gleiche Problem.

Vorerst meine package.json enthalten nicht alle meine sdk, aber ich möchte so etwas wie haben:

"dependencies": { 
    "my-sdk": "2.0.0" 
    "my-sdk-legacy": "1.0.0" 
} 

Oder

"dependencies": { 
    "my-sdk": ["2.0.0", "1.0.0"] 
} 

Ich habe nichts anderes gefunden noch. Ich denke darüber nach, die erste Version meines SDK-Pakets mit einem anderen Namen wie "my-sdk-legacy" zu veröffentlichen, aber das möchte ich wenn möglich vermeiden.

Irgendeine Lösung dafür?

Answer 1

Also das ist eigentlich ein recht häufiges Szenario, das mehrmals angesprochen wurde.

Es gibt ein geschlossenes Problem für npm und offene Ausgabe für yarn Paketmanager.

---

Die erste Lösung wurde vom Autor von NPM in this GH Kommentar vorgeschlagen:

ein separates Paket unter einem anderen Namen veröffentlichen. Es wird eine spezielle Version benötigt.

{ "name": "express3", 
    "version": "1.0.0", 
    "description":"Express version 3", 
    "dependencies": { "express":"3" } } 

// index.js 
module.exports = require('express') 

In Ihrem Fall werden Sie my-sdk-v1 und my-sdk-v2 veröffentlichen. Und ab sofort können Sie problemlos 2 Versionen eines Pakets in einem Projekt installieren, ohne dass Konflikte auftreten.

const mySDKLegacy = require('my-sdk-v1'); 
const mySDKModern = require('my-sdk-v2'); 

Die second way so ziemlich die gleiche Idee vorgeschlagen - Verwendung git url:

{ 
    "my-sdk-v1": "git://github.com/user/my-sdk#1.0.0", 
    "my-sdk-v2": "git://github.com/user/my-sdk#2.0.0" 
} 

Im Gegensatz zu npm Paket, Sie sind frei, einen beliebigen Namen wollen wählen! Die Quelle der Wahrheit ist die Git-URL.

Laternpm-install-version aufgetaucht. Buuut, wie Sie bereits bewiesen haben, ist seine Verwendung ein bisschen begrenzt. Da es einen untergeordneten Prozess hervorbringt, um einige Befehle auszuführen und in tmp-Verzeichnisse zu schreiben. Nicht der zuverlässigste Weg für ein CLI.

Zusammenfassend: Sie sind mit den Möglichkeiten 1 & 2. Ich würde mit dem ersten bleiben, da der Github Repo Name & Tags ändern könnte.

Die zweite Option mit git URL ist besser, wenn Sie eine Version häufiger abhängig ändern möchten. Stellen Sie sich vor, Sie möchten einen Sicherheitspatch für my-sdk-v1-Legacy veröffentlichen. Es wird einfacher sein, eine Git-URL zu referenzieren und dann my-sdk-v1.1 immer wieder auf npm zu veröffentlichen.