Me encontré con el mismo problema con fsevents en Windows, al instalar dos paquetes que dependen de diferentes versiones de 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

El último webpack depende del watchpack, que depende de un [email protected] anterior, que depende de un antiguo [email protected].

Mientras que chokidar último depende de [email protected]

Pero npm install omitió correctamente ambas versiones de fsevents ya que son incompatibles con el sistema operativo.

Sin embargo:

 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

Y si miro en node_modules, fsevents está ahí y no debería estar.
Además, npm ci --no-optional no funciona, esto se informa aquí: https://github.com/npm/cli/issues/637

Estoy usando la instalación de Nodo 12 LTS, npm -v => 6.13.4

Si npm ci --no-optional funciona puede depender de factores adicionales. Ver https://github.com/npm/cli/issues/637#issuecomment -570813804

Entonces, mientras npm ci falla en mi entorno, npm ci --no-optional funciona. Mi entorno:

• Windows 10
• Nodejs 12.13.1
• npm 6.13.4

Después de actualizar al último nodo y npm tienen el mismo problema ... todos los proyectos donde es fsevent fallan al instalar con npm ci , porque está construyendo fsevents

• Windows 10 Pro 1909
• nodo 12.14.1
• npm 6.13.6

Después de actualizar al último nodo y npm tienen el mismo problema ... todos los proyectos donde es fsevent fallan al instalar con npm ci , porque está construyendo fsevents

* Windows 10 Pro 1909

* node 12.14.1

* npm 6.13.6

@padinko ¿También --no-optional , es decir, npm ci --no-optional ? ¿Alguna diferencia?

Después de actualizar al último nodo y npm tienen el mismo problema ... todos los proyectos donde es fsevent fallan al instalar con npm ci , porque está construyendo fsevents

* Windows 10 Pro 1909

* node 12.14.1

* npm 6.13.6

@padinko ¿También --no-optional , es decir, npm ci --no-optional ? ¿Alguna diferencia?

npm ci fallan con estos paquetes:

\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 solo tienen 2 de ellos:

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

así que ahí está la diferencia, pero aún compilando fsevents

@paulmillr @pipobscure Mi problema (# 658) fue un duplicado de este ticket. Sigue este para mantenerte actualizado.

Puedo confirmar este error también en Ubuntu. npm ci instala fsevents que debe instalarse solo en MacOS

@mikemimik o @isaacs , ¿tiene alguna opinión sobre este error? Sí, fsevents cambió algo por lo que ahora es un problema mayor. Pero el problema subyacente sigue siendo causado por la NPM y debería resolverse aquí.

Parece que el cambio relevante es que fsevents comenzó a usar node-pre-gyp para extraer un binario precompilado, en lugar de construirlo en su lugar, lo que resulta en un script postinstall que sale sin errores en todas las plataformas. Dado que npm ci solo intenta diseñar lo que esté en el archivo de bloqueo sin verificar si es compatible con la plataforma, y ​​solo elimina deps opcionales cuyos scripts de instalación fallan, resulta en la instalación de este dep.

npm v7 no tendrá este problema. (Estoy trabajando en el código que hará esto ahora). No he comprobado qué tan complicado sería solucionar este problema para npm v6, pero hay muchas posibilidades de que termine siendo "actualización a v7 para corregir ". Mientras tanto, te recomiendo usar npm install lugar de npm ci si esto te está afectando.

Sí, fsevents cambió su táctica. Pero en realidad es al revés. Solían tener binarios precompilados. La instalación en Windows daría un 404 y omitiría. Ahora intenta construir y luego rompe la construcción. Porque la compilación ni siquiera debería comenzar. Independientemente: npm ci está diseñado para entornos de CI. ¿Cómo deberíamos usar npm i lugar? Queremos controles estrictos de bloqueo de paquetes en CI.

Además: ¿ npm@7 aterrizaría en el nodo 14, a tiempo antes de que sea LTS? ¿Estoy en lo correcto al suponer que estamos atrapados con npm i o un bloqueo de versión durante un año cuando estamos en la pista LTS?

Perdón por cambiar de táctica contigo. Sin embargo, perdimos el acceso al S3 utilizado originalmente y se estaba convirtiendo en un problema de seguridad cada vez más grave. Por eso volvimos a construir según fuera necesario. Especialmente dado que v2.x basado en NAPI no necesita compilarse en absoluto para el nodo v8.x +

Ahora intenta construir y luego rompe la construcción. Porque la compilación ni siquiera debería comenzar.

Oh, eso es raro. Esperaría que npm ci maneje una falla de compilación de un departamento opcional como un evento de tipo de advertencia no fatal, y simplemente elimine el departamento ofensivo.

Independientemente: npm ci está diseñado para entornos de CI. ¿Por qué deberíamos usar npm i en su lugar? Queremos controles estrictos de bloqueo de paquetes en CI.

Buena pregunta.

"Diseñado para entornos de CI" no siempre significa "lo mejor para este entorno de CI en particular, para esta aplicación en particular".

En este caso, hay dos problemas con los que se está encontrando npm ci.

• No está manejando correctamente las fallas de compilación para los departamentos opcionales.
• No puede filtrar previamente los departamentos según las restricciones del sistema operativo / CPU, porque _sólo_ mira el paquete-lock.json, donde no se rastrea esa información. (Es decir, es más rápido porque omite algunas lecturas de archivos normalmente innecesarias; incluido, incorrectamente, el único archivo que contiene la información necesaria para evitar correctamente este error).

Por lo tanto, debe usar npm i lugar de npm ci porque funcionará, evitando ambos errores.

Queremos controles estrictos de bloqueo de paquetes en CI.

Si está hablando del hecho de que el bloqueo de paquetes proporciona las verificaciones autorizadas de integridad y resolución, entonces buenas noticias: npm install hace.

Si está hablando de la verificación de que package-lock y package.json están sincronizados entre sí, puede agregar "scripts": { "prepare": "npx lock-verify" } a su package.json.

¿ Npm @ 7 aterrizaría en el nodo 14, a tiempo antes de que sea LTS?

Esa es mi expectativa, sí.

Pero, incluso si es LTS, el enfoque en el pasado ha sido tener una versión LTS de npm en la versión LTS del nodo, incluso si eso significa que cambia dentro del período de tiempo "congelado" de LTS, por lo que se envía npm v6 para 4 años sería una idea profundamente mala que no creo que Node sirva. Y como npm es en realidad una especie de proyecto independiente, en lugar de una "dependencia" que afecte al tiempo de ejecución, esto suele estar bien.

Dado que npm v7 tendrá algunos cambios importantes (aunque estamos tratando de minimizarlos tanto como sea posible), puede ser un problema si no lo hacemos a tiempo, o podemos hacer algunas concesiones para establecer configuraciones predeterminadas o Haga otras cosas para que el npm v7 que se envía con el nodo 14 LTS esté lo más cerca posible de npm v6.

Oh, acabo de comprobar el horario del nodo y veo que estaba equivocado sobre el plazo. El lanzamiento _inicial_ del Nodo 14 es en 3 meses, pero no será LTS hasta octubre.

Así que sí, deberíamos estar bien despejados. Espero que la versión inicial de npm v7 esté disponible a tiempo para el nodo 14 y sea más que suficientemente estable para cuando v14 llegue a LTS. (Últimas palabras famosas y todo eso, pero la confianza ha ido aumentando a medida que nos acercamos a la integración, y no tengo ninguna razón para pensar que eso cambiará pronto).

Me sorprende que esto no esté siendo tratado como un error más importante que lo que es. Esto hace que no podamos usar "npm ci" en nuestros servidores de compilación en Windows. Eso es muy importante.

No solo Windows, no puedo usar npm ci en ningún sistema

Si está hablando del hecho de que el bloqueo de paquetes proporciona las verificaciones autorizadas de integridad y resolución, entonces buenas noticias: npm install hace.

Espere ... ha sido mi experiencia que npm install potencialmente resultará en la actualización del archivo package-lock.json si hay nuevos paquetes disponibles que aún se adhieren a las reglas establecidas en el archivo package.json.

¿Esta funcionalidad ha cambiado @isaacs ?

@tommck creo que lo aborda con esta parte:

Si está hablando de la verificación de que package-lock y package.json están sincronizados entre sí, puede agregar "scripts": { "prepare": "npx lock-verify" } a su package.json.

Supongo que puede usarlo como una implementación de hombre pobre de npm ci en su entorno de CI. Ejecutaría npm install ; esto ejecuta el script de preparación que verifica si el bloqueo del paquete todavía está sincronizado con su package.json.

Si no me equivoco, esto tiene dos problemas:

• No veo cómo esto maneja las actualizaciones de las dependencias indirectas que satisfacen las restricciones de sus dependencias directas. Esos se actualizarán y su compilación incluiría un código más nuevo.
• Si la verificación de bloqueo detecta cambios, está obteniendo una compilación fallida de la nada. Tendría que volver a generar y confirmar el package-lock.json actualizado. Me gustaría que mis compilaciones fueran predecibles, que no fallaran cuando se libera alguna dependencia.

Así que sí, es un gran problema - afortunadamente en nuestro caso construimos en linux y todavía funcionan para nuestra combinación de paquetes ... Otras personas tienen menos suerte.

@coyoteecd Entonces ... asumiendo que el archivo de bloqueo estaba bien (correcto / verificado), ¿ejecutar "npm install" aún podría modificar el archivo de bloqueo del paquete con nuevas dependencias?

ejecutar "npm install" todavía podría modificar el archivo de bloqueo del paquete con nuevas dependencias?

Incorrecto. No hará eso.

Ejecutar npm install sin argumentos no agregará ninguna dependencia que difiera de lo que está en el archivo de bloqueo.

Lo que hará npm install , que npm ci _no_ hará, es _skip_ descargar dependencias que están en node_modules y que ya coinciden con lo que está en el archivo de bloqueo.

Espere ... ha sido mi experiencia que npm install potencialmente resultará en la actualización del archivo package-lock.json si hay nuevos paquetes disponibles que aún se adhieren a las reglas establecidas en el archivo package.json.

¿Esta funcionalidad ha cambiado @isaacs ?

Me encantaría ver un caso en el que eso suceda. A menos que le esté diciendo explícitamente que no respete el archivo de bloqueo, o ejecute npm update , o que el archivo de bloqueo no sea válido (es decir, los departamentos no tienen sus dependencias cumplidas por el árbol que define), el archivo de bloqueo ha bloqueado npm install desde que se introdujo en npm v5.

full-icu es el paquete, que a veces cambia el archivo de bloqueo ... pero creo que es su problema, no npm

mis experiencias: cuando tiene el nodo v12 y otro desarrollador tiene v10, paquete de datos de icu de degradación completa de icu para el nodo v10 ..

cuando tiene un bloqueo con todo y no hay node_modules directorio npm i , eliminará los datos de icu del archivo de bloqueo, debe ejecutar npm i segunda vez para agregarlo nuevamente.

estábamos usando npm ci, debido a estos 2 problemas

Para cualquier otra persona que termine aquí debido a fsevents , esta es la solución npm ci de su problema correspondiente:

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

@jayoungers FWIW, esa solución no funcionó para mí. De alguna manera, todavía se está construyendo una versión diferente de fsevents con npm ci . Tuve que cambiar mis procesos de compilación para usar npm i lugar.

¿Hay alguna actualización sobre esto? También nos afecta este error.

No estoy seguro de si esto ayuda, pero encontré este problema al ejecutar npm install en un paquete donde package-lock.json ya se había generado en Linux (WSL en mi caso). Después de eliminar package-lock.json y volver a ejecutar npm install en Windows, estaba bien.

Parece que Serverless Pro CI cambió de npm install a npm ci y este problema también ocurre y rompe la compilación
Me estoy comprometiendo desde una máquina de 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 

Usar npm install --no-optional no funciona como solución alternativa.

el momento está marcado como opcional en 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
 }

Cuando elimino el momento de node_modules npm i lo devolveré:

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

ls node_modules | grep moment 
moment

@Elijen No creo que sea el mismo problema del que trata este hilo, que son los objetivos del sistema operativo para los paquetes. Es posible que desee presentar un problema por separado si aún no existe uno.

Ah, y por cierto, fsevents ya no tiene este problema desde el 5 de mayo:
https://github.com/fsevents/fsevents/issues/301

@isaacs ¿Esto aterrizó en npm@7 ?

@paulirwin Quizás tengas razón. Vi varios problemas y publicaciones en foros creados sobre el problema que mencioné y asumí que este es solo un problema posterior causado por él.

Me encantaría ver un caso en el que eso suceda. A menos que le esté diciendo explícitamente que no respete el archivo de bloqueo, o ejecute npm update , o que el archivo de bloqueo no sea válido (es decir, los departamentos no tienen sus dependencias cumplidas por el árbol que define), el archivo de bloqueo ha bloqueado npm install desde que se introdujo en npm v5.

He visto dependencias de actualización de npm install con un archivo de bloqueo válido en v6.14.8, cuando las versiones del paquete se especifican por etiqueta. Registrado como # 2167.

La buena noticia es que no parece estar sucediendo en v7.0.10: +1: