我正在使用 NodeJS 中的 CLI 工具,它使用我们开发的另一个 NodeJs 包,它是一个 SDK。
问题是,我们刚刚发布了该 SDK 的 V2 版本,我们希望为 CLI 用户提供传统模式,以便他们可以使用我们 SDK 的第一个或第二个版本,如下所示:
$ cli do-stuff
#execute sdk v2
或者
$ LEGACY_MODE='on' cli do-stuff
#execute sdk v1
我的问题是我没有找到任何干净的方法来在我的 CLI 中使用相同依赖项的两个版本。我尝试使用 npm-install-version 包。它在我的本地环境中运行良好,但是在发布我的 cli 并执行 npm install -g my-cli
之后,它不再起作用,因为它在当前文件夹中创建了一个 node_modules 文件夹,而不是 /usr/local/lib/node_modules/my-cli
文件夹。我也试过 multidep ,我也有同样的问题。
目前,我的 package.json 根本不包含我的 sdk,但我想要类似的东西:
"dependencies": {
"my-sdk": "2.0.0"
"my-sdk-legacy": "1.0.0"
}
或者
"dependencies": {
"my-sdk": ["2.0.0", "1.0.0"]
}
我还没有找到其他任何东西。我正在考虑使用另一个名称发布我的 sdk 包的第一个版本,例如“my-sdk-legacy”,但如果可能的话,我想避免这种情况。
有什么解决方案吗?
原文由 Greg 发布,翻译遵循 CC BY-SA 4.0 许可协议
所以这实际上是一个非常常见的场景,已经多次解决。
npm 有一个已关闭的问题, 纱线 包管理器有一个未解决的问题。
第一个解决方案是 NPM 的作者在 这个 GH 评论中提出的:
以不同的名称发布单独的包。它将需要内部的特定版本。
在您的情况下,您将发布
my-sdk-v1
和my-sdk-v2
。从现在开始,您可以轻松地在一个项目中安装 2 个版本的包,而不会发生冲突。第二种方式 几乎与提出的想法相同 - 使用 git url:
与 npm 包不同,您可以自由选择任何您想要的名称!事实的来源是 git url。
后来
npm-install-version
弹出。 Buuut,正如您已经证明的那样,它的使用有点有限。因为它会产生一个子进程来执行一些命令并写入 tmp 目录。不是 CLI 最可靠的方法。总结一下:剩下的选择 1 和 2。我会坚持第一个,因为 github 存储库名称和标签可能会改变。
当您想要更改版本以更频繁地依赖时,带有 git url 的第二个选项会更好。假设您想为 my-sdk-v1 legacy 发布一个安全补丁。引用 git url 会更容易,然后一次又一次地将
my-sdk-v1.1
发布到 npm。