标签: npm-shrinkwrap

最近发现npm-audit并在第一次运行时标记了很多漏洞，主要是围绕包及其依赖项。

想要解决我发现的这些漏洞npm shrinkwrap，这允许我指定应该使用哪些版本及其依赖项？反正我是这么看的（如果有错，请纠正我，在这里学习）。

我试图修复的一个例子是模块hoek，在我package.json这里被设置为"hoek": "^5.0.3"

当我运行npm shrinkwrap其中一个依赖项已hoek设置为版本 2

"boom": {
  "version": "2.10.1",
  "resolved": "https://registry.npmjs.org/boom/-/boom-2.10.1.tgz",
  "integrity": "sha1-OciRjO/1eZ+D+UkqhI9iWt0Mdm8=",
  "requires": {
    "hoek": "2.x.x"
  },
  "dependencies": {
    "hoek": {
      "version": "2.16.3",
      "resolved": "https://registry.npmjs.org/hoek/-/hoek-2.16.3.tgz",
      "integrity": "sha1-ILt0A9POo5jpHcRxCo/xuCdKJe0="
    }
  }
},

我想我可以编辑它并指定我希望依赖项使用的版本

  "boom": {
  "version": "2.10.1",
  "resolved": "https://registry.npmjs.org/boom/-/boom-2.10.1.tgz",
  "integrity": "sha1-OciRjO/1eZ+D+UkqhI9iWt0Mdm8=",
  "dev": true,
  "requires": {
    "hoek": "2.x.x"
  },
  "dependencies": {
    "hoek": {
      "version": "5.0.3",
      "resolved": "https://registry.npmjs.org/hoek/-/hoek-5.0.3.tgz",
      "integrity": "sha1-ILt0A9POo5jpHcRxCo/xuCdKJe0=",
      "dev": true
    }
  }
},

但是，当我运行npm …

我的package-lock.json并且package.json没有指定用于在我的存储库中生成的node.js 版本package-lock.json。

我可以使用迭代node版本来nvm查看哪个版本git diff对我的存储库中的前一个package-lock文件的产量最小。我想知道是否有一种不那么详尽和繁琐的方法可以做到这一点。是否有任何提示可以从锁定文件中“逆向工程”或“提取”节点版本？

动机：我不想package-lock.json在每次提交时不断更改我的版本，并且在 CI 中始终使用相同的节点版本。

我有一个 monorepo 项目，其中一个包是 cli。为了防止 npm 供应链攻击，我正在考虑使用npm-shrinkwrap.

这里的文档说：

npm-shrinkwrap.json 的推荐用例是通过注册表上的发布过程部署的应用程序：例如，用作全局安装或 devDependency 的守护程序和命令行工具

这正是我在部署命令行工具时想要的。唯一的问题是，npm-shrinkwrap 似乎不支持工作区。

假设我的 monorepo 的 cli 部分可以在路径中找到：/code/packages/cli，当我切换到它并运行时，npm shrinkwrap我收到错误：

npm ERR! code ENOWORKSPACES
npm ERR! This command does not support workspaces.

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/me/.npm/_logs/2022-05-16T20_53_41_147Z-debug-0.log

如果我切换到项目的根目录，即/code/运行npm shrinkwrap，它会生成npm-shrinkwrap.json具有以下结构的：

{
  "name": "root",
  "version": "1.0.0",
  "lockfileVersion": 2,
  "requires": true,
  "packages": {
    "": {
      "name": "root",
      "version": "1.0.0",
      "license": "ISC", …

我有一个正在处理的自定义 npm 模块，它有一个 GitHub 存储库。我也在做一个使用自定义模块的项目。在处理较大的项目时，使用起来很好，npm link因此我可以对模块进行更改并立即在主项目中看到它们。

为了部署到暂存或生产，我使用了shrinkwrap和shrinkpack，所以我可以npm install在每次部署之后做一个（一些依赖项需要二进制文件，而开发系统与生产系统不同，所以它们确实需要安装，而不仅仅是保留在源代码管理中）。 编辑：我将这一点划掉，因为下面的答案在技术上解决了我的问题，即使它没有解决这个特定的问题，但这并不像其他问题那么重要。

当然，由于模块链接到我的主项目并且未在 中列出package.json，因此部署和安装完全错过了它。我可以继续并列出它package.json并让它指向适当的 GitHub 存储库，但是每次我需要测试主项目中的更改时，我都必须提交并推送这些更改，然后更新主项目，杀死并重新启动应用程序……这很快就会让人厌烦。

我想我需要类似于“devDependencies”的东西；东西在那里我可以把它不能安装在开发的模块，但不这样做，当从GitHub安装npm install上登台或生产。除了记住package.json每次需要来回手动更改之外，还有更好的方法吗？

我正在使用 webpack 和 npm 模块构建我的网站代码，并遇到以下问题：

我的代码使用 jQuery 3.1.1 并添加了一些插件。我还使用了对 jQuery <= 2.2.4 具有子依赖性的依赖项。问题是，子依赖项的对象显然不知道我的 jQuery 插件，因为该模块使用不同的 jquery 版本。

如何强制所有依赖项（顶级和嵌套）使用一个版本的 jQuery？所以require("jquery")总是解析为 jQuery 3.1.1。

我尝试使用 npm Shrinkwrap 来覆盖依赖项版本，但这似乎不起作用。这是我修改后的收缩包装文件：

{
  "name": "example",
  "version": "0.1.0",
  "dependencies": {
    "can": {
      "version": "2.3.27",
      "from": "can@>=2.3.23 <3.0.0",
      "resolved": "https://registry.npmjs.org/can/-/can-2.3.27.tgz",
      "dependencies": {
        "jquery": {
          "version": "3.1.1",
          "from": "^3.1.1"
        }
      }
    }
  }
}

但模块的依赖项仍然是 jQuery 2.2.4 并npm install打印npm ERR! invalid: jquery@3.1.1 /path/.../can/node_modules/jquery

使用 webpack 而不是 npm 解决问题的解决方案也被接受。

我已经诊断了这个问题几天了,并且已经测试了针对"meteor"和"npm"依赖项出现的顶级问题解决方案,这些解决方案与此类似.我和我的后端工程师都很难过.

我使用的是OSX 10.10.3,ruby 1.9.3,节点v0.10.36,npm 1.4.28,meteor 1.1.02.

此外,我不是代理的背后,因为错误似乎表明.

我的环境路径是:

export PATH ="/ usr/local/bin:/ usr/bin:/ bin:/ usr/sbin:/ sbin"

这是错误:

=> Started proxy.                             
=> Started MongoDB.                           
npm-container: updating npm dependencies -- hummus, shipping-ups...
npm WARN package.json packages-for-meteor-smartpackage-1wscwem@0.0.0 No
description
npm WARN package.json packages-for-meteor-smartpackage-1wscwem@0.0.0 No
repository field.
npm WARN package.json packages-for-meteor-smartpackage-1wscwem@0.0.0 No README
data
../src/deps/LibTiff/tif_unix.c:140:6: warning: cast to 'thandle_t' (aka 'void
*') from smaller integer type 'int' [-Wint-to-void-pointer-cast]
(thandle_t) fd,
^
1 warning generated.
../src/deps/LibTiff/tif_write.c:633:49: warning: comparison of integers of
different signs: …