Ich habe das gleiche Problem mit fsevents unter Windows festgestellt, als ich zwei Pakete installiert habe, die von verschiedenen Versionen von fsevents abhängen.

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

Das neueste Webpack hängt vom Watchpack ab, das von einem älteren [email protected] abhängt, das von einem alten [email protected] abhängt.

Während Chokidar spätestens von [email protected] abhängt

Die npm-Installation hat jedoch beide Versionen von fsevents korrekt übersprungen, da sie nicht mit dem Betriebssystem kompatibel sind.

Jedoch:

 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

Und wenn ich in node_modules nachschaue, ist fsevents da und sollte es nicht sein.
Außerdem funktioniert npm ci --no-optional nicht. Dies wird hier gemeldet: https://github.com/npm/cli/issues/637

Ich verwende die Node 12 LTS-Installation, npm -v => 6.13.4

Ob npm ci --no-optional funktioniert, kann von zusätzlichen Faktoren abhängen. Siehe https://github.com/npm/cli/issues/637#issuecomment -570813804

Während npm ci in meiner Umgebung fehlschlägt, funktioniert npm ci --no-optional . Meine Umgebung:

• Windows 10
• Knoten 12.13.1
• npm 6.13.4

Nach dem Update auf den neuesten Knoten und npm tritt das gleiche Problem auf. Alle Projekte, bei denen es sich um fsevent handelt, können nicht mit npm ci installiert werden, da fsevents erstellt werden

• Windows 10 Pro 1909
• Knoten 12.14.1
• npm 6.13.6

Nach dem Update auf den neuesten Knoten und npm tritt das gleiche Problem auf. Alle Projekte, bei denen es sich um fsevent handelt, können nicht mit npm ci installiert werden, da fsevents erstellt werden

* Windows 10 Pro 1909

* node 12.14.1

* npm 6.13.6

@padinko Haben Sie auch die Variante mit dem zusätzlichen Flag --no-optional ausprobiert, dh npm ci --no-optional ? Jede Differenz?

Nach dem Update auf den neuesten Knoten und npm tritt das gleiche Problem auf. Alle Projekte, bei denen es sich um fsevent handelt, können nicht mit npm ci installiert werden, da fsevents erstellt werden

* Windows 10 Pro 1909

* node 12.14.1

* npm 6.13.6

@padinko Haben Sie auch die Variante mit dem zusätzlichen Flag --no-optional ausprobiert, dh npm ci --no-optional ? Jede Differenz?

npm ci schlagen mit diesen Paketen fehl:

\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 haben nur 2 davon:

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

da ist also ein unterschied, aber immer noch fsevents kompilieren

@paulmillr @pipobscure Mein Problem (# 658) war ein Duplikat dieses Tickets. Verfolgen Sie diese, um auf dem neuesten Stand zu bleiben.

Ich kann diesen Fehler auch unter Ubuntu bestätigen. npm ci installiert fsevents , das nur unter MacOS installiert werden sollte

@mikemimik oder @isaacs , hast du irgendwelche Eingaben zu diesem Fehler? Ja, fsevents hat etwas geändert, warum dies jetzt ein größeres Problem ist. Das zugrunde liegende Problem wird jedoch immer noch durch NPM verursacht und sollte hier gelöst werden.

Es sieht so aus, als ob die relevante Änderung darin besteht, dass fsevents begonnen hat, Node-Pre-Gyp zu verwenden, um eine vorkompilierte Binärdatei abzurufen, anstatt sie an Ort und Stelle zu erstellen, was zu einem postinstall -Skript führt, das auf allen Plattformen fehlerfrei beendet wird. Da npm ci nur versucht, alles in der Sperrdatei anzuordnen, ohne zu prüfen, ob es die Plattform unterstützt, und nur optionale Deps entfernt, deren Installationsskripte fehlschlagen, führt dies zur Installation dieser Dep.

npm v7 wird dieses Problem nicht haben. (Ich arbeite an dem Code, der dies jetzt erledigt.) Ich habe nicht geprüft, wie kompliziert es wäre, dieses Problem für npm v6 zu beheben, aber es besteht eine gute Chance, dass es sich nur um ein "Upgrade" handelt zu v7 für den Fix ". In der Zwischenzeit würde ich empfehlen, npm install anstelle von npm ci wenn dies Sie betrifft.

Ja, fsevents ihre Taktik geändert. Aber es ist tatsächlich umgekehrt. Früher hatten sie vorkompilierte Binärdateien. Die Installation unter Windows würde einen 404 ergeben und überspringen. Jetzt versucht es zu bauen und bricht dann den Build ab. Weil der Build nicht einmal beginnen sollte. Unabhängig davon: npm ci wurde für CI-Umgebungen entwickelt. Wie sollen wir dann stattdessen npm i verwenden? Wir wollen die strengen Paketsperrprüfungen in CI.

Außerdem: Würden npm@7 rechtzeitig vor dem LTS auf Knoten 14 landen? Kann ich zu Recht davon ausgehen, dass wir ein Jahr lang mit npm i oder einer Versionssperre im LTS-Track feststecken?

Entschuldigen Sie, dass Sie die Taktik geändert haben. Wir haben jedoch den Zugriff auf den ursprünglich verwendeten S3 verloren und er wurde zu einem zunehmend ernsten Sicherheitsproblem. Deshalb haben wir nach Bedarf wieder gebaut. Insbesondere angesichts der Tatsache, dass v2.x, das auf NAPI basiert, für den Knoten v8.x + überhaupt nicht erstellt werden muss

Jetzt versucht es zu bauen und bricht dann den Build ab. Weil der Build nicht einmal beginnen sollte.

Oh, das ist komisch. Ich würde erwarten, dass npm ci einen Build-Fehler von einem optionalen Dep als nicht schwerwiegendes Warnereignis behandelt und einfach das fehlerhafte Dep entfernt.

Unabhängig davon: npm ci wurde für CI-Umgebungen entwickelt. Warum sollten wir dann stattdessen npm i verwenden? Wir wollen die strengen Paketsperrprüfungen in CI.

Gute Frage.

"Entwickelt für CI-Umgebungen" bedeutet nicht immer "am besten für diese bestimmte CI-Umgebung, für diese bestimmte Anwendung".

In diesem Fall gibt es zwei Probleme, auf die npm ci stößt.

• Build-Fehler für optionale Deps werden nicht ordnungsgemäß behandelt.
• Es ist nicht in der Lage, Deps basierend auf Betriebssystem- / CPU-Einschränkungen vorzufiltern, da es _nur_ nur die package-lock.json betrachtet, in der diese Informationen nicht verfolgt werden. (Das heißt, es ist schneller, da einige normalerweise unnötige Dateilesevorgänge übersprungen werden, einschließlich fälschlicherweise der einzigen Datei, die die Informationen enthält, die erforderlich sind, um diesen Fehler ordnungsgemäß zu vermeiden.)

Sie sollten also npm i anstelle von npm ci da dies funktioniert und beide Fehler vermieden werden.

Wir wollen die strengen Paketsperrprüfungen in CI.

Wenn Sie über die Tatsache sprechen, dass die Paketsperre die maßgeblichen Integritäts- und Auflösungsprüfungen bietet, dann ist dies eine gute Nachricht: npm install macht das auch.

Wenn Sie über die Überprüfung sprechen, ob die Paketsperre und package.json miteinander synchronisiert sind, können Sie Ihrer package.json "scripts": { "prepare": "npx lock-verify" } hinzufügen.

Würde npm @ 7 rechtzeitig vor LTS auf Knoten 14 landen?

Das ist meine Erwartung, ja.

Aber selbst wenn es sich um LTS handelt, bestand der Ansatz in der Vergangenheit darin, eine LTS-Version von npm in der LTS-Version des Knotens zu haben, auch wenn dies bedeutet, dass sie sich innerhalb des "eingefrorenen" LTS-Zeitrahmens ändert, sodass npm v6 für 4 ausgeliefert wird Jahre wären eine zutiefst schlechte Idee, von der ich nicht glaube, dass Node sie tun wird. Und da npm wirklich eher ein separates Projekt als eine "Abhängigkeit" ist, die sich auf die Laufzeit auswirkt, ist dies normalerweise in Ordnung.

Da npm v7 einige wichtige Änderungen aufweisen wird (obwohl wir versuchen, diese so gering wie möglich zu halten), kann es ein Problem sein, wenn wir es nicht rechtzeitig erhalten, oder wir machen einige Zugeständnisse, um Standardkonfigurationen festzulegen oder Machen Sie andere Dinge, damit die mit Knoten 14 LTS gelieferte npm v7 so nah wie möglich an npm v6 liegt.

Oh, ich habe gerade den Zeitplan des Knotens überprüft und

Also ja, wir sollten klar sein. Ich gehe davon aus, dass die Erstveröffentlichung von npm v7 rechtzeitig für Knoten 14 verfügbar sein wird und mehr als ausreichend stabil sein wird, wenn v14 LTS erreicht. (Berühmte letzte Worte und alles, aber das Vertrauen hat stetig zugenommen, als wir uns der Integration näherten, und ich habe keinen Grund zu der Annahme, dass sich dies bald ändern wird.)

Ich bin überrascht, dass dies nicht als wichtiger für einen Fehler angesehen wird, als es ist. Dies macht es so, dass wir "npm ci" nicht auf unseren Build-Servern in Windows verwenden können. Das ist eine große Sache.

Nicht nur Windows, ich kann npm ci auf keinem System verwenden

Wenn Sie über die Tatsache sprechen, dass die Paketsperre die maßgeblichen Integritäts- und Auflösungsprüfungen bietet, dann ist dies eine gute Nachricht: npm install macht das auch.

Warten Sie. Ich habe die Erfahrung gemacht, dass npm install möglicherweise zur Aktualisierung der Datei package-lock.json führt, wenn neue Pakete verfügbar sind, die weiterhin den in der Datei package.json festgelegten Regeln entsprechen.

Hat diese Funktionalität @isaacs geändert?

@tommck Ich denke, er spricht das mit diesem Teil an:

Wenn Sie über die Überprüfung sprechen, ob die Paketsperre und package.json miteinander synchronisiert sind, können Sie Ihrer package.json "scripts": { "prepare": "npx lock-verify" } hinzufügen.

Vermutlich können Sie es als Implementierung von npm ci einen armen Mann in Ihrer CI-Umgebung verwenden. Sie würden npm install ausführen; Dadurch wird das Vorbereitungsskript ausgeführt, das prüft, ob die Paketsperre noch mit Ihrer package.json synchronisiert ist.

Wenn ich mich nicht irre, hat dies zwei Probleme:

• Ich sehe nicht, wie dies mit Aktualisierungen indirekter Abhängigkeiten umgeht, die die Einschränkungen Ihrer direkten Abhängigkeiten erfüllen. Diese würden aktualisiert und Ihr Build würde neueren Code enthalten.
• Wenn Lock-Verify Änderungen erkennt, wird aus heiterem Himmel ein fehlgeschlagener Build angezeigt. Sie müssten die aktualisierte package-lock.json neu generieren und festschreiben. Ich möchte, dass meine Builds vorhersehbar sind und nicht fehlschlagen, wenn eine Abhängigkeit freigegeben wird.

Also ja, es ist ein großes Problem - zum Glück bauen wir in unserem Fall auf Linux auf und sie funktionieren immer noch für unsere Kombination von Paketen ... Andere Menschen haben weniger Glück.

@coyoteecd Also ... unter der Annahme, dass die Sperrdatei in Ordnung war (korrekt / verifiziert), könnte das Ausführen von "npm install" die

Wenn Sie "npm install" ausführen, wird die Paketsperrdatei möglicherweise immer noch mit neuen Abhängigkeiten geändert.

Falsch. Das wird es nicht tun.

Wenn Sie npm install ohne Argumente ausführen, werden keine Abhängigkeiten hinzugefügt, die sich von den Angaben in der Sperrdatei unterscheiden.

Was npm install tun wird, was npm ci nicht tun wird, ist _skip_ Herunterladen von Abhängigkeiten, die sich in node_modules und bereits mit dem übereinstimmen, was in der Sperrdatei enthalten ist.

Warten Sie. Ich habe die Erfahrung gemacht, dass die Installation von npm möglicherweise zur Aktualisierung der Datei package-lock.json führt, wenn neue Pakete verfügbar sind, die weiterhin den in der Datei package.json festgelegten Regeln entsprechen.

Hat diese Funktionalität @isaacs geändert?

Ich würde gerne einen Fall sehen, in dem das passiert. Sofern Sie nicht ausdrücklich anweisen, die Sperrdatei nicht zu respektieren oder npm update auszuführen, oder die Sperrdatei ungültig ist (dh Deps haben ihre Abhängigkeiten nicht durch den von ihr definierten Baum erfüllt), hat die Sperrdatei npm install gesperrt

full-icu ist ein Paket, das manchmal die Sperrdatei ändert. Aber ich denke, es ist ihr Problem, nicht npm

Meine Erfahrungen: Wenn Sie Node v12 haben und ein anderer Entwickler v10 hat, wird das ICU-Datenpaket für Node v10 vollständig heruntergestuft.

Wenn Sie mit allem gesperrt sind und kein node_modules -Verzeichnis haben und npm i ausführen, werden ICU-Daten aus der Sperrdatei entfernt. Sie müssen npm i zweiten Mal ausführen, um sie erneut hinzuzufügen.

Aufgrund dieser beiden Probleme haben wir npm ci verwendet

Für alle anderen, die aufgrund von fsevents hier landen, ist dies die npm ci Lösung aus dem entsprechenden Problem:

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

@ Jayoungers FWIW, diese Lösung hat bei mir nicht funktioniert. Irgendwie wird immer noch eine andere Version von fsevents mit npm ci . Ich musste meine Erstellungsprozesse ändern, um stattdessen npm i verwenden.

Gibt es Updates dazu? Wir sind auch von diesem Fehler betroffen.

Ich bin mir nicht sicher, ob dies hilft, aber ich bin auf dieses Problem gestoßen, als ich npm install in einem Paket ausgeführt habe, in dem package-lock.json bereits unter Linux generiert wurde (in meinem Fall WSL). Nachdem ich package-lock.json gelöscht und npm install in Windows erneut ausgeführt hatte, ging es mir gut.

Anscheinend wurde Serverless Pro CI von npm install auf npm ci geändert, und dieses Problem tritt auch auf und bricht den Build ab
Ich begebe mich von einer Windows-Maschine

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 

Die Verwendung von npm install --no-optional funktioniert nicht als Problemumgehung.

Moment ist in package-lock.json als optional markiert:

"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
 }

Wenn ich den Moment aus den Knotenmodulen entferne, wird er von npm i zurückgesetzt:

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

ls node_modules | grep moment 
moment

@Elijen Ich glaube nicht, dass dies das gleiche Problem ist wie in diesem Thread, bei dem es sich um Betriebssystemziele für Pakete handelt. Möglicherweise möchten Sie ein separates Problem einreichen, falls noch keines vorhanden ist.

Oh, und übrigens, fsevents hat dieses Problem seit dem 5. Mai nicht mehr:
https://github.com/fsevents/fsevents/issues/301

@isaacs Ist dieses Land in npm@7 gelandet ?

@ Paulirwin Vielleicht hast du recht. Ich habe mehrere Probleme und Forenbeiträge zu dem von mir erwähnten Problem gesehen und angenommen, dass dies nur ein nachgelagertes Problem ist, das dadurch verursacht wird.

Ich würde gerne einen Fall sehen, in dem das passiert. Sofern Sie nicht ausdrücklich anweisen, die Sperrdatei nicht zu respektieren oder npm update auszuführen, oder die Sperrdatei ungültig ist (dh Deps haben ihre Abhängigkeiten nicht durch den von ihr definierten Baum erfüllt), hat die Sperrdatei npm install gesperrt

Ich habe npm install Update-Abhängigkeiten mit einer gültigen Sperrdatei in Version 6.14.8 gesehen, wenn Paketversionen durch Tag angegeben werden. Als # 2167 angemeldet.

Die gute Nachricht ist, dass es in Version 7.0.10 nicht zu passieren scheint: +1: