Dwie wersje tego samego pakietu NPM w aplikacji Node

Question

Pracuję nad narzędziem CLI w NodeJS, które wykorzystuje inny pakiet NodeJs, który rozwijamy, czyli SDK.

Rzecz w tym, że właśnie opublikował wersję V2 tego SDK i chcemy zaoferować użytkownikowi CLI trybu legacy, więc mogą używać zarówno pierwszą lub drugą wersję SDK, tak:

$ cli do-stuff 
#execute sdk v2 

Albo

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

moim problemem jest to, że nie znaleziono żadnych czystą drogę do korzystania z dwóch wersji tego samego uzależnienia w moim CLI. Próbowałem użyć pakietu npm-install-version. Działa dobrze na moim lokalnym środowisku, ale po opublikowaniu mojego cli i wykonaniu npm install -g my-cli, to już nie działa, ponieważ tworzy folder node_modules w bieżącym folderze zamiast folderu /usr/local/lib/node_modules/my-cli. Próbowałem również multidep i mam tego samego problemu.

Na razie mój package.json nie zawierają w ogóle mojego SDK, ale chciałbym mieć coś takiego:

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

Albo

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

nie znalazłem niczego innego jeszcze. Zastanawiam się nad opublikowaniem pierwszej wersji mojego pakietu SDK z inną nazwą, np. "My-sdk-legacy", ale chciałbym tego uniknąć, jeśli to możliwe.

Jakieś rozwiązanie tego?

Answer 1

Tak więc jest to dość powszechny scenariusz, który był adresowany kilka razy.

Istnieje zamknięty numer dla npm i otwarty numer dla menedżerów pakietów yarn.

---

Pierwsze rozwiązanie zostało zaproponowane przez autora KMP w this GH Komentarz:

publikuje oddzielny pakiet pod inną nazwą. Będzie wymagać określonej wersji w środku.

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

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

W twoim przypadku będziesz publikować my-sdk-v1 i my-sdk-v2. Od tej pory możesz łatwo zainstalować 2 wersje pakietu w jednym projekcie bez konfliktów.

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

second way prawie ten sam pomysł zaproponowany - wykorzystanie 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" 
} 

przeciwieństwie do pakietu npm, jesteś wolny, aby wybrać dowolną nazwę, którą chcesz! Źródłem prawdy jest adres URL git.

Laternpm-install-version pojawił się. Buuut, jak już wykazałeś, jego użycie jest nieco ograniczone. Ponieważ odradza proces potomny do wykonywania niektórych poleceń i zapisuje do katalogów tmp. Nie jest to najbardziej niezawodny sposób na CLI.

Podsumowując: pozostało Ci do wyboru 1 & 2. Pozostałbym przy pierwszym, ponieważ tagi nazwy repo Githuba mogły zostać zmienione na &.

Druga opcja z adresem URL git jest lepsza, gdy chcesz zmienić wersję, aby częściej polegać. Wyobraź sobie, że chcesz opublikować poprawkę zabezpieczeń dla dziedzictwa my-sdk-v1. Łatwiej będzie odwołać się do URL-a git, a następnie opublikować my-sdk-v1.1 na npm raz za razem.