異なるバージョンのfseventsに依存する2つのパッケージをインストールするときに、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は、古い[email protected]に依存する古いwatchpackに依存しています。

最新のchokidarは[email protected]に依存していますが

しかし、npm installは、OSと互換性がないため、両方のバージョンの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機能します。 私の環境：

• ウィンドウズ10
• Nodejs 12.13.1
• npm 6.13.4

最新のノードとnpmに更新した後、同じ問題が発生します。fseventをビルドしているため、fseventであるすべてのプロジェクトはnpm ciでインストールできません。

• Windows 10 Pro 1909
• ノード12.14.1
• npm 6.13.6

最新のノードとnpmに更新した後、同じ問題が発生します。fseventをビルドしているため、fseventであるすべてのプロジェクトはnpm ciでインストールできません。

* Windows 10 Pro 1909

* node 12.14.1

* npm 6.13.6

@padinko --no-optionalフラグが追加されたバリアント、つまりnpm ci --no-optionalも試しましたか？ 違いはありますか？

最新のノードとnpmに更新した後、同じ問題が発生します。fseventをビルドしているため、fseventであるすべてのプロジェクトはnpm ciでインストールできません。

* 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は2つしかありません：

\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がインストールされます。

npmv7ではこの問題は発生しません。 （私は今これを行うコードで作業しています。）npm v6でこの問題を修正することがどれほど関与するかについてはチェックしていませんが、「アップグレード」になる可能性は十分にあります。修正のためにv7に」。 それまでの間、影響がある場合は、 npm ciではなくnpm installを使用することをお勧めします。

はい、 fseventsは彼らの戦術を変えました。 しかし、実際にはその逆です。 以前は、バイナリがプリコンパイルされていました。 Windowsにインストールすると、404が返され、スキップされます。 今度はビルドを試みてから、ビルドを中断します。 ビルドを開始するべきではないからです。 関係なく： npm ciはCI環境向けに設計されています。 代わりにnpm iをどのように使用する必要がありますか？ CIでの厳密なパッケージロックチェックが必要です。

また、LTSになる前に、 npm@7はノード14に到達しますか？ LTSトラックにいるときに、 npm iまたはバージョンロックで1年間スタックしていると想定するのは正しいですか？

戦術を変えてすみません。 ただし、元々使用されていたS3にアクセスできなくなり、セキュリティの深刻な問題になりつつありました。 そのため、必要に応じてビルドに戻りました。 特に、NAPIに基づくv2.xは、ノードv8.x +用にビルドする必要がまったくないことを考えると

今度はビルドを試みてから、ビルドを中断します。 ビルドを開始するべきではないからです。

ああ、それは変だ。 npm ciは、オプションのdepからのビルドの失敗を致命的ではない警告タイプのイベントとして処理し、問題のあるdepを削除するだけだと思います。

関係なく：npmciはCI環境向けに設計されています。 なぜ代わりにnpmiを使用する必要があるのですか？ CIでの厳密なパッケージロックチェックが必要です。

良い質問。

「CI環境向けに設計された」とは、必ずしも「この特定のCI環境、この特定のアプリケーションに最適」を意味するわけではありません。

この場合、npmciが直面している2つの問題があります。

• オプションの部門のビルドの失敗を適切に処理していません。
• os / CPUの制限に基づいてdepsを事前にフィルタリングすることはできません。これは、その情報が追跡されていないpackage-lock.jsonのみを参照するためです。 （つまり、通常は不要なファイルの読み取りをスキップするため、高速です。誤って、この失敗を適切に回避するために必要な情報を含む唯一のファイルが含まれます。）

したがって、両方のバグを回避して機能するため、 npm ciではなくnpm iを使用する必要があります。

CIでの厳密なパッケージロックチェックが必要です。

パッケージロックが信頼できる整合性と解決のチェックを提供するという事実について話しているなら、朗報です。 npm installもそれを行います。

package-lockとpackage.jsonが互いに同期していることの確認について話している場合は、package.jsonに"scripts": { "prepare": "npx lock-verify" }を追加できます。

npm @ 7はLTSになる前にノード14に着陸しますか？

それが私の期待です、はい。

ただし、LTSであっても、これまでのアプローチでは、LTSの「凍結」時間枠内で変更されたとしても、LTSバージョンのノードにLTSバージョンのnpmを含めることでした。 Nodeがやらないと思うので、何年もは非常に悪い考えです。 また、npmは実際には別のプロジェクトのようなものであり、実行時に影響を与えるような「依存関係」ではないため、通常は問題ありません。

npm v7にはいくつかの重大な変更があるため（これらを可能な限り最小化しようとしていますが）、時間内に到達しない場合は問題になる可能性があります。または、デフォルトの構成を設定するために譲歩する可能性があります。ノード14LTSに同梱されているnpmv7がnpmv6にできるだけ近くなるように、他のことを行います。

ああ、ノードのスケジュールを確認したところ、時間枠について間違っていたことがわかりました。 ノード14の_初期_リリースは3か月ですが、LTSは10月まで行われません。

そうそう、私たちははっきりしているはずです。 npm v7の初期リリースは、ノード14に間に合うように利用可能になり、v14がLTSに到達するまでに十分に安定していると思います。 （有名な最後の言葉ですが、統合に近づくにつれて自信は着実に高まっており、それがすぐに変わると思う理由はありません。）

これがバグよりも重要なものとして扱われていないことに驚いています。 これにより、Windowsのビルドサーバーで「npmci」を使用できなくなります。 それは大したことです。

Windowsだけでなく、どのシステムでもnpmciを使用できません

パッケージロックが信頼できる整合性と解決のチェックを提供するという事実について話しているなら、朗報です。 npm installもそれを行います。

待ってください..package.jsonファイルに設定されたルールに準拠した新しいパッケージが利用可能な場合、 npm installによってpackage-lock.jsonファイルが更新される可能性があるのは私の経験です。

この機能は@isaacsに変更され

@tommck彼はこの部分でそれに対処していると思います：

package-lockとpackage.jsonが互いに同期していることの確認について話している場合は、package.jsonに"scripts": { "prepare": "npx lock-verify" }を追加できます。

CI環境での貧乏人のnpm ciの実装として使用できると思います。 npm installます; これにより、package-lockがまだpackage.jsonと同期しているかどうかを確認するprepareスクリプトが実行されます。

私が間違っていなければ、これには2つの問題があります。

• これが、直接の依存関係の制約を満たす間接的な依存関係の更新をどのように処理するのかわかりません。 それらは更新され、ビルドには新しいコードが含まれます。
• lock-verifyが変更を検出した場合、失敗したビルドが突然発生します。 更新されたpackage-lock.jsonを再生成してコミットする必要があります。 ビルドが予測可能であり、依存関係が解放されたときに失敗しないようにしたいと思います。

そうですね、それは大きな問題です。幸いなことに、私たちの場合はLinuxでビルドを行っていますが、パッケージの組み合わせでも機能します...他の人はそれほど幸運ではありません。

@coyoteecdだから...ロックファイルが正常（正しい/検証済み）であると仮定すると、「npm install」を実行しても、新しい依存関係でパッケージロックファイルが変更される可能性がありますか？

「npminstall」を実行しても、新しい依存関係でパッケージロックファイルが変更される可能性がありますか？

不正解です。 それはしません。

引数なしでnpm installを実行しても、ロックファイルの内容と異なる依存関係は追加されません。

npm installが実行すること、 npm ciが実行しないことは、 node_modulesあり、すでにロックファイルにあるものと一致する依存関係をダウンロードすることです。

待ってください..package.jsonファイルに設定されたルールに準拠した新しいパッケージが利用可能な場合、npminstallによってpackage-lock.jsonファイルが更新される可能性があるのは私の経験です。

この機能は@isaacsに変更され

それが起こるケースを見てみたいです。 ロックファイルを尊重しないように明示的に指示している場合、またはnpm update場合、またはロックファイルが無効である場合（つまり、depsが定義するツリーによって依存関係が満たされていない場合）を除いて、ロックファイルはnpm installをロックダウンしています。 npm v5で導入されて以来、

full-icuはパッケージであり、ロックファイルを変更することがあります。しかし、それは彼らの問題であり、npmではないと思います。

私の経験：ノードv12があり、別の開発者がv10を持っている場合、ノードv10用のフルicuダウングレードicuデータパッケージ。

すべてがロックされていてnode_modulesディレクトリがなく、 npm iを実行すると、ロックファイルからicuデータが削除されます。もう一度追加するには、 npm iもう一度実行する必要があります。

この2つの問題のため、npmciを使用していました

fsevents原因でここにたどり着いた他の人にとって、これは対応する問題からのnpm ciソリューションです。

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

@jayoungers FWIW、その解決策は私にはうまくnpm ci構築されています。 代わりにnpm iを使用するようにビルドプロセスを変更する必要がありました。

これに関する更新はありますか？ このバグの影響も受けています。

これが役立つかどうかはわかりませんが、Linux（私の場合はWSL）でpackage-lock.jsonが既に生成されているパッケージでnpm installを実行すると、この問題が発生しました。 package-lock.jsonを削除し、Windowsでnpm installを再実行した後、問題はありませんでした。

Serverless ProCIがnpminstallからnpmciに変更されたようで、この問題も発生し、ビルドが中断されます
私は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ターゲットであるこのスレッドと同じ問題ではないと思います。 まだ存在しない場合は、別の問題を提出することをお勧めします。

ちなみに、 fseventsは、5月5日以降この問題は発生していません。
https://github.com/fsevents/fsevents/issues/301

@isaacsこの土地はnpm@7か？

@paulirwinたぶんあなたは正しいです。 私が言及した問題について作成された複数の問題とフォーラム投稿を見て、これはそれによって引き起こされた単なる下流の問題であると思いました。

それが起こるケースを見てみたいです。 ロックファイルを尊重しないように明示的に指示している場合、またはnpm update場合、またはロックファイルが無効である場合（つまり、depsが定義するツリーによって依存関係が満たされていない場合）を除いて、ロックファイルはnpm installをロックダウンしています。 npm v5で導入されて以来、

パッケージのバージョンがタグで指定されている場合、v6.14.8で有効なロックファイルを使用してnpm install依存関係を更新するのを見てきました。 ＃2167として記録されました。

幸いなことに、v7.0.10では発生していないようです：+1：