安装两个依赖于不同版本的fsevents的软件包时，我在Windows上遇到了与fsevents相同的问题。

npm install chokidar --save

npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules\fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"darwin","arch":"any"} (current: {"os":"win32","arch":"x64"})

+ [email protected]
added 14 packages from 17 contributors and audited 19 packages in 1.668s
found 0 vulnerabilities

npm install webpack --save-dev

npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules\watchpack\node_modules\fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"darwin","arch":"any"} (current: {"os":"win32","arch":"x64"})

+ [email protected]
added 327 packages from 195 contributors and audited 4246 packages in 16.581s

最新的webpack取决于watchpack，而watchpack取决于较旧的[email protected] ，而后者取决于较旧的[email protected]。

虽然chokidar最新取决于[email protected]

但是npm install正确跳过了两个版本的fsevents，因为它们与操作系统不兼容。

然而：

 npm ci
npm WARN prepare removing existing node_modules/ before installation

> [email protected] install K:\SWS\test\node_modules\watchpack\node_modules\fsevents
> node-gyp rebuild


K:\SWS\test\node_modules\watchpack\node_modules\fsevents>if not defined npm_config_node_gyp (node "C:\Program Files\nodejs\node_modules\npm\node_modules\npm-lifecycle\node-gyp-bin\\..\..\node_modules\node-gyp\bin\node-gyp.js" rebuild )  else (node "C:\Program Files\nodejs\node_modules\npm\node_modules\node-gyp\bin\node-gyp.js" rebuild )
Traceback (most recent call last):
  File "C:\Program Files\nodejs\node_modules\npm\node_modules\node-gyp\gyp\gyp_main.py", line 50, in <module>
    sys.exit(gyp.script_main())
  File "C:\Program Files\nodejs\node_modules\npm\node_modules\node-gyp\gyp\pylib\gyp\__init__.py", line 554, in script_main
    return main(sys.argv[1:])
  File "C:\Program Files\nodejs\node_modules\npm\node_modules\node-gyp\gyp\pylib\gyp\__init__.py", line 547, in main
    return gyp_main(args)
  File "C:\Program Files\nodejs\node_modules\npm\node_modules\node-gyp\gyp\pylib\gyp\__init__.py", line 532, in gyp_main
    generator.GenerateOutput(flat_list, targets, data, params)
  File "C:\Program Files\nodejs\node_modules\npm\node_modules\node-gyp\gyp\pylib\gyp\generator\msvs.py", line 2033, in GenerateOutput
    root_entries = _GatherSolutionFolders(
  File "C:\Program Files\nodejs\node_modules\npm\node_modules\node-gyp\gyp\pylib\gyp\generator\msvs.py", line 1791, in _GatherSolutionFolders
    return _DictsToFolders('', root, flat)
  File "C:\Program Files\nodejs\node_modules\npm\node_modules\node-gyp\gyp\pylib\gyp\generator\msvs.py", line 1744, in _DictsToFolders
    for folder, contents in bucket.items():
AttributeError: 'MSVSProject' object has no attribute 'items'
gyp ERR! configure error
gyp ERR! stack Error: `gyp` failed with exit code: 1
gyp ERR! stack     at ChildProcess.onCpExit (C:\Program Files\nodejs\node_modules\npm\node_modules\node-gyp\lib\configure.js:351:16)
gyp ERR! stack     at ChildProcess.emit (events.js:210:5)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:272:12)
gyp ERR! System Windows_NT 10.0.17134
gyp ERR! command "C:\\Program Files\\nodejs\\node.exe" "C:\\Program Files\\nodejs\\node_modules\\npm\\node_modules\\node-gyp\\bin\\node-gyp.js" "rebuild"
gyp ERR! cwd K:\SWS\test\node_modules\watchpack\node_modules\fsevents
gyp ERR! node -v v12.14.0
gyp ERR! node-gyp -v v5.0.5
gyp ERR! not ok
added 275 packages in 9.344s

如果我查看node_modules，fsevents就在那儿，不应该。
此外， npm ci --no-optional不起作用，这是在这里报告的： https ：

我正在使用Node 12 LTS安装， npm -v => 6.13.4

npm ci --no-optional有效可能取决于其他因素。 参见https://github.com/npm/cli/issues/637#issuecomment -570813804

因此，虽然npm ci在我的环境中失败，但npm ci --no-optional仍然有效。 我的环境：

• Windows 10
• Nodejs 12.13.1
• npm 6.13.4

更新到最新节点和npm后，存在相同的问题..所有位于fsevent的项目均无法使用npm ci进行安装，因为它正在构建fsevents

• Windows 10专业版1909
• 节点12.14.1
• npm 6.13.6

更新到最新节点和npm后，存在相同的问题..所有位于fsevent的项目均无法使用npm ci进行安装，因为它正在构建fsevents

* Windows 10 Pro 1909

* node 12.14.1

* npm 6.13.6

@padinko您是否也尝试了带有附加--no-optional标志的变量，即npm ci --no-optional ？ 有什么区别吗？

更新到最新节点和npm后，存在相同的问题..所有位于fsevent的项目均无法使用npm ci进行安装，因为它正在构建fsevents

* Windows 10 Pro 1909

* node 12.14.1

* npm 6.13.6

@padinko您是否也尝试了带有附加--no-optional标志的变量，即npm ci --no-optional ？ 有什么区别吗？

npm ci与此软件包失败：

\node_modules\watchpack\node_modules\fsevents
\node_modules\webpack-dev-server\node_modules\fsevents
\node_modules\jest-haste-map\node_modules\fsevents

npm ci --no-optional只有两个：

\node_modules\webpack-dev-server\node_modules\fsevents
\node_modules\jest-haste-map\node_modules\fsevents

所以有区别，但仍在编译fsevents

@paulmillr @pipobscure我的问题（＃658）是这张票的重复。 跟踪此内容以保持最新。

我也可以在Ubuntu上确认此错误。 npm ci将安装仅应在MacOS上安装的fsevents

@mikemimik或@isaacs ，您对此错误有任何输入吗？ 是的， fsevents改变了一些原因，为什么这现在是一个更大的问题。 但是潜在的问题仍然是由NPM引起的，应在此处解决。

看起来相关的更改是fsevents开始使用node-pre-gyp来提取预编译的二进制文件，而不是将其构建到位，从而导致postinstall脚本在所有平台上均无错误地退出。 由于npm ci只是试图对锁定文件中的内容进行布局而不检查其是否支持该平台，并且仅删除安装脚本失败的可选dep，因此将导致安装此dep。

npm v7不会有此问题。 （我正在使用现在将要执行此操作的代码。）我尚未检查过如何解决npm v6的此问题，但是很有可能最终会被“升级”修复到v7”。 同时，如果这会影响您，我建议您使用npm install而不是npm ci 。

是的， fsevents改变了战术。 但这实际上是另一回事。 他们曾经有预编译的二进制文件。 在Windows上安装将显示404，然后跳过。 现在它尝试构建，然后中断构建。 因为构建甚至不应该开始。 无论如何： npm ci是为CI环境设计的。 那么我们应该如何使用npm i呢？ 我们希望在CI中进行严格的程序包锁定检查。

另外： npm@7是否可以在LTS之前及时到达节点14？ 我是否正确地假设我们在LTS跟踪中停留了一年的npm i或版本锁？

很抱歉改变您的战术。 但是，我们无法使用最初使用的S3，并且它已成为一个日益严重的安全问题。 这就是为什么我们根据需要重新构建。 特别是考虑到基于NAPI的v2.x根本不需要为节点v8.x +构建

现在它尝试构建，然后中断构建。 因为构建甚至不应该开始。

哦，那很奇怪。 我希望npm ci作为非致命警告类型事件来处理来自可选dep的构建失败，并且只需删除有问题的dep。

无论如何：npm ci是为CI环境设计的。 为什么我们应该改为使用npm i？ 我们希望在CI中进行严格的程序包锁定检查。

好问题。

“为CI环境设计”并不总是意味着“对于此特定CI环境，对于此特定应用程序来说是最佳”。

在这种情况下，npm ci会遇到两个问题。

• 它不能正确处理可选dep的构建失败。
• 它无法根据os / cpu限制预先过滤dep，因为_only_会查看package-lock.json，在该信息中不会跟踪该信息。 （也就是说，它更快，因为它会跳过一些通常不必要的文件读取；错误地包括唯一包含正确避免此故障所需信息的文件。）

因此，您应该使用npm i而不是npm ci因为它可以正常工作，避免出现两个错误。

我们希望在CI中进行严格的程序包锁定检查。

如果您在谈论包锁提供权威性完整性和解决方案检查的事实，那么好消息： npm install也可以做到这一点。

如果您正在谈论检查package-lock和package.json是否彼此同步，则可以将"scripts": { "prepare": "npx lock-verify" }到package.json中。

npm @ 7是否会在LTS之前及时登陆节点14？

那是我的期望，是的。

但是，即使是LTS，过去的方法是在节点的LTS版本中使用npm的LTS版本，即使这意味着它在LTS“冻结”的时间范围内更改，因此将npm v6发行为4我认为Node不会做很多年，这将是一个非常糟糕的主意。 而且由于npm实际上是一个单独的项目，而不是以影响运行时的方式进行“依赖”，所以通常很好。

由于npm v7会有一些重大更改（尽管我们正在尝试将这些更改最小化），所以如果我们不及时将其更改可能会成问题，或者我们可能会做出一些让步来设置默认配置或请执行其他操作，以使节点14 LTS附带的npm v7尽可能接近npm v6。

哦，我只是检查了节点的计划，发现我误认为时间框架了。 节点14的_initial_版本在3个月内发布，但直到10月才会发布。

是的，我们应该很清楚。 我希望npm v7的初始版本将在节点14上及时提供，并且在v14达到LTS时已经足够稳定。 （著名的遗言以及所有这些，但是随着我们离整合越来越近，信心一直在稳步上升，我没有任何理由认为这种情况很快就会改变。）

令我惊讶的是，它没有被视为更重要的错误。 这样可以避免在Windows中的构建服务器上使用“ npm ci”。 没关系

不只是Windows，我不能在任何系统上使用npm ci

如果您在谈论包锁提供权威性完整性和解决方案检查的事实，那么好消息： npm install也可以做到这一点。

等等，根据我的经验，如果有新的软件包仍然遵守package.json文件中设置的规则，则npm install可能会导致更新package-lock.json文件。

此功能是否已更改@isaacs ？

@tommck我想他用这一部分来解决这个问题：

如果您正在谈论检查package-lock和package.json是否彼此同步，则可以将"scripts": { "prepare": "npx lock-verify" }到您的package.json中。

猜猜您可以将其用作CI环境中npm ci的穷人实现。 您将运行npm install ; 这将运行准备脚本，该脚本检查程序包锁是否仍与您的package.json同步。

如果我没记错的话，这有两个问题：

• 我看不到它如何处理满足您直接依赖项约束的间接依赖项更新。 这些将被更新，并且您的构建将包含更新的代码。
• 如果lock-verify检测到更改，则说明您的构建失败了。 您必须重新生成并提交更新的package-lock.json。 我希望自己的构建是可预测的，不要在某些依赖被释放时失败。

是的，这是一个大问题-幸运的是，在我们的情况下，我们确实在Linux上构建，但它们仍然适用于我们的软件包组合……其他人则不太幸运。

@coyoteecd所以...假设锁定文件是正确的（正确/已验证），运行“ npm install”是否仍可以使用新的依赖项修改软件包锁定文件？

运行“ npm install”仍可能会使用新的依赖项修改程序包锁定文件？

不正确它不会那样做。

不带参数运行npm install不会添加任何与锁文件中的内容不同的依赖项。

npm install将要执行的操作， npm ci将_不_做的是_skip_下载在node_modules已经与锁文件中的内容匹配的依赖项。

等等，这是我的经验，如果有新软件包可用，仍然会遵循package.json文件中设置的规则，那么npm install可能会导致更新package-lock.json文件。

此功能是否已更改@isaacs ？

我很想看看发生这种情况的情况。 除非您明确告诉它不遵守锁定文件，或者运行npm update ，或者锁定文件无效（即，deps的依赖关系未由其定义的树满足），否则锁定文件将锁定npm install自npm v5引入以来。

full-icu是软件包，有时会更改锁定文件..但我认为这是他们的问题，而不是npm

我的经验：当您拥有节点v12，而另一位开发人员拥有v10时，则将节点v10的ICU数据包完全降级​​。

当您拥有所有东西的锁并且没有node_modules目录并运行npm i ，它将从锁文件中删除ICU数据，您需要再次运行npm i来再次添加它。

我们正在使用npm ci，因为这2个问题

对于因fsevents而到这里结束的其他人，这是相应问题的npm ci解决方案：

https://github.com/fsevents/fsevents/issues/301#issuecomment -572607085

@jayoungers FWIW，该解决方案对我不起作用。 仍然以某种方式使用npm ci构建不同版本的fsevents。 我不得不更改构建过程以改为使用npm i 。

是否有任何更新？ 我们也受到此错误的影响。

不确定这是否有帮助，但是在Linux中已经生成package-lock.json的程序包中运行npm install时遇到了这个问题（在我的例子中为WSL）。 在删除package-lock.json并在Windows中重新运行npm install之后，我很好。

似乎Serverless Pro CI从npm install更改为npm ci，并且还会出现此问题并中断构建
我从Windows计算机上提交

build step: npm ci

> [email protected] postinstall /nuxt-serverless/node_modules/core-js
> node -e "try{require('./postinstall')}catch(e){}"


> [email protected] postinstall /nuxt-serverless/node_modules/ejs
> node ./postinstall.js


> [email protected] install /nuxt-serverless/node_modules/watchpack/node_modules/fsevents
> node-gyp rebuild

gyp
 ERR! build error 
gyp
 ERR! stack Error: not found: make
gyp ERR! stack     at getNotFoundError (/root/.nvm/versions/node/v10.13.0/lib/node_modules/npm/node_modules/which/which.js:13:12)
gyp
 ERR! stack     at F (/root/.nvm/versions/node/v10.13.0/lib/node_modules/npm/node_modules/which/which.js:68:19)
gyp ERR! stack
     at E (/root/.nvm/versions/node/v10.13.0/lib/node_modules/npm/node_modules/which/which.js:80:29)
gyp ERR! stack     at /root/.nvm/versions/node/v10.13.0/lib/node_modules/npm/node_modules/which/which.js:89:16
gyp ERR! 
stack     at /root/.nvm/versions/node/v10.13.0/lib/node_modules/npm/node_modules/isexe/index.js:42:5
gyp ERR! stack     at /root/.nvm/versions/node/v10.13.0/lib/node_modules/npm/node_modules/isexe/mode.js:8:5
gyp 
ERR! stack     at FSReqWrap.oncomplete (fs.js:154:21)
gyp ERR! 
System Linux 4.14.171-105.231.amzn1.x86_64
gyp ERR! command "/root/.nvm/versions/node/v10.13.0/bin/node" "/root/.nvm/versions/node/v10.13.0/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /nuxt-serverless/node_modules/watchpack/node_modules/fsevents
gyp ERR!
 node -v v10.13.0
gyp ERR! node-gyp -v v3.8.0
gyp ERR! not ok 

使用npm install --no-optional不能解决。

在package-lock.json标记为“可选”：

"moment": {
      "version": "2.29.1",
      "resolved": "https://registry.npmjs.org/moment/-/moment-2.29.1.tgz",
      "integrity": "sha512-kHmoybcPV8Sqy59DwNDY3Jefr64lK/by/da0ViFcuA4DH0vQg5Q6Ze5VimxkfQNSC+Mls/Kx53s7TjP1RhFEDQ==",
      "dev": true,
      "optional": true
 }

当我从node_modules删除片刻时， npm i会把它放回去：

rm -rf node_modules/moment
npm install --no-optional

ls node_modules | grep moment 
moment

@Elijen我不认为这与该线程所涉及的问题相同，后者是软件包的OS目标。 如果一个问题不存在，则可能要提出一个单独的问题。

哦，顺便说一下，自5月5日起， fsevents不再有此问题：
https://github.com/fsevents/fsevents/issues/301

@isaacs这土地落在npm@7吗？

@paulirwin也许你是对的。 我看到有关我提到的问题的多个问题和论坛帖子都创建了，并假定这只是由它引起的下游问题。

我很想看看发生这种情况的情况。 除非您明确告诉它不遵守锁定文件，或者运行npm update ，或者锁定文件无效（即，deps的依赖关系未由其定义的树满足），否则锁定文件将锁定npm install自npm v5引入以来。

当软件包版本由tag指定时，我已经在v6.14.8上看到npm install具有有效锁定文件的更新依赖项。 记录为＃2167。

好消息是在v7.0.10：+1中似乎没有发生这种情况：