当包具有公共依赖项时,私有包的 npm 安装失败

ysf*_*ran 6 npm npm-install npm-registry

可以说我有一个私人NPM库,内举办JFrog artifactory的https://my-domain.com/artifactory/api/npm/my-repo。在这个存储库中,我发布了一个 npm package: my-package,它构建得很好。my-package依赖(或更多)公共 npm包,例如lodash.

但是,当我创建一个新项目并尝试安装时my-package,出现以下错误:

$ npm install my-package --registry https://my-domain.com/artifactory/api/npm/my-repo
npm ERR! code E404
npm ERR! 404 Not Found - GET https://my-domain.com/artifactory/api/npm/my-repo/lodash - not_found
npm ERR! 404
npm ERR! 404  'lodash^4.17.11' is not in the npm registry.
npm ERR! 404 You should bug the author to publish it (or use the name yourself!)
npm ERR! 404 It was specified as a dependency of 'my-package'
npm ERR! 404
npm ERR! 404 Note that you can also install from a
npm ERR! 404 tarball, folder, http url, or git url.

npm ERR! A complete log of this run can be found in:
npm ERR!     C:\Users\<username>\AppData\Roaming\npm-cache\_logs\2019-04-29T12_47_51_647Z-debug.log
Run Code Online (Sandbox Code Playgroud)

这看起来好像npm是我的私人信息库的所有依赖内进行搜索my-package时,我指定的要求--registry运行时的选项npm install。但是,my-package依赖于公共依赖项,这些依赖项不在我的私有注册表中。

我的问题

如何从具有公共依赖项的私有注册表安装 npm 包?也许这也只是 JFrog 的问题?

任何帮助将不胜感激!

Nat*_*han 3

通过指定注册表:--registry https://my-domain.com/artifactory/api/npm/my-repo npm 正在尝试从您的私有存储库位置按名称和版本解析所有必需的包domain.com/artifactory/api/npm/my-repo

要解决您的私有库所依赖的这些公共依赖项,您有两种选择:

  1. 设置虚拟 Npm 注册表。(推荐这个方法)
  2. 将所有必要的依赖项打包到您的私有存储库中。

Artifactory 中定义的虚拟存储库聚合来自本地和远程存储库的包。这允许您从为虚拟存储库定义的单个 URL 访问本地托管的 npm 包和远程代理的 npm 注册表

通过设置引用您的私有存储库位置和默认公共 npmjs 位置的虚拟存储库,您将能够通过指定上述注册表来下载您的私有库以及任何公共 npm 包。

既然您提到,JFrog请查看他们的融合页面,该页面将引导您完成创建虚拟存储库的过程。

但是,如果您决定使用选项 2,则必须将所有必要的依赖项打包到您的私有存储库中。然后你的私有库将能够正确地提取它所依赖的依赖项。我建议不要采用这种方法,因为您将重复已经提供的工作npmjs,并且您还必须不断更新您的私有存储库以包含新库或现有库的更新版本。

希望这有帮助!

  • 不确定这是否正是 @ysfaran 的意思,但在我的例子中,我使用的是 `.npmrc`,解决方案是使用以下行指定我的组织范围的私有注册表地址:`@my-org:registry= https://npm.pkg.github.com/my-org`。这样,在我的 `package.json` 中,包 `@my-org/my-package` 是唯一可以通过私有注册表检索的包,所有其他包都从默认的公共注册表中检索。 (5认同)
  • 还有第三个选项是 [npm 作用域包](https://docs.npmjs.com/misc/scope)。这就是我实际上想出的解决方案,因为它最适合我的情况。对我来说唯一的缺点是,我必须将我的包重命名为范围包。(`@范围/...`) (2认同)