Yarn: No advierta sobre dependencias opcionales incompatibles

Me parece un uso apropiado de advertir.

¿No sería mejor arreglar lo que está dando la advertencia en lugar de simplemente ocultarlo?

@wtgtybhertgeghgtwtg

¿Qué quieres decir con "arreglar"? Como se explica en https://github.com/npm/npm/issues/11632 , todo funciona según lo previsto. Algunos paquetes dependen de fsevents específicamente en macOS (porque ofrece una experiencia superior) pero recurren a otro comportamiento en Windows / Linux. El hecho de que fsevents es incompatible con Windows no debe ser revelado a los usuarios: es solo un detalle de implementación específico de la plataforma de una dependencia. No hay nada procesable para los usuarios allí (y nada de qué alarmarse).

Yo diría que requerir una dependencia y agregar binarios para un sistema operativo específico no debería ser la forma en que funciona.
Estoy seguro de que hay otros paquetes que hacen que surja este problema, pero fsevents es el más predominante, obteniendo problemas en babel , webpack , su create-react-app , y seguro que muy pronto sane y jest . Creo que sería más productivo encontrar una mejor solución de observación de archivos en lugar de cambiar el comportamiento de un administrador de paquetes debido a las deficiencias de un paquete.

Si tiene una sugerencia alternativa sobre lo que podrían hacer los paquetes que usan fsevents (o fsevents ), ¡me gustaría escuchar eso! Sin embargo, no creo que haya nada "malo" en tener un paquete que sea específico del sistema operativo. Resuelve un problema real y algunos problemas son específicos de la plataforma.

Parece que las opiniones están divididas.
Supongo que advertir sobre algo no procesable podría ser molesto.
Por otro lado, advertencias similares, por ejemplo, "este módulo no funciona en Node.js <4", son bastante útiles.
¿Hay alguna configuración que la gente pueda activar para desactivar las advertencias?

@gaearon dado que se trata de un repositorio de código abierto, ¿qué tal un PR para agregar una marca CLI para suprimir por nivel de registro? Sería muy incorrecto empapelar un problema posterior en los paquetes a los que hace referencia, ya sea una computadora superior o solo un RPi de $ 35 que puede hacer la mayoría de las mismas cosas.

@jhabdas

¿Qué tal un PR para agregar una bandera CLI para suprimir por nivel de registro?

Me hubiera encantado enviar un PR pero, como @bestander , también trabajo a tiempo completo en el mantenimiento de otros proyectos de código abierto y, lamentablemente, no tengo tiempo para trabajar en esta función en particular. Planteé un tema para discutir si es deseable o no.

Sería muy incorrecto empapelar un problema posterior en los paquetes a los que hace referencia, ya sea una computadora superior o solo un RPi de $ 35 que puede hacer la mayoría de las mismas cosas.

No entiendo este comentario. No estoy sugiriendo "empapelar un tema posterior". fsevents no está haciendo nada malo. Quiere expresar que solo es útil en macOS, pero no existe en otros sistemas. Otros paquetes, como webpack , quieren expresar que les gustaría usar fsevents en macOS, pero quieren omitirlo en otros sistemas. Y esto es exactamente lo que están haciendo tanto yarn como npm.

Todo ya funciona según lo previsto, excepto que tanto npm como yarn también imprimen un mensaje que parece aterrador pero que en realidad no indica un problema . Pero no hay ninguna razón para que el usuario se preocupe porque todo funciona según lo previsto. Mi punto es que sería bueno dejar de asustar a los usuarios cuando no pasa nada.

Lo siento si no estoy siendo muy claro. Puedo ver ahora que esto es más controvertido de lo que esperaba. Entonces no hagamos esto. No voy a morir en esta colina. 😛

Por otro lado, advertencias similares, por ejemplo, "este módulo no funciona en Node.js <4", son bastante útiles.

... pero eso es procesable: puede actualizar su versión de Node.js.

... pero eso es procesable: puede actualizar su versión de Node.js.

La limitación del sistema operativo también podría ser procesable.
Supongo que la pregunta es si vale la pena mostrar la misma advertencia cada vez que instale una herramienta IO que no esté en una Mac, creo que deberíamos darles a los usuarios de Windows la oportunidad de no mostrarlos cuando las dependencias son opcionales.

Volveré a abrir, parece que vale la pena discutir más.

Probablemente podríamos degradar esto a un nivel de registro de "información" (e introducir el concepto de niveles de registro como lo ha hecho npm).

@gearon ¿Podría proporcionar dos casos de prueba complementarios, por favor? Leí los detalles y escuché la sugerencia. Pero me gustaría asimilar personalmente lo que consideras una experiencia aterradora para los principiantes por algo que "casi nunca es procesable". Mencionaste Webpack arriba. Para mí, Webpack en sí es aterrador y no lo uso como resultado. Hay muchas cosas geniales que se pueden hacer con hilo si mantiene sus ojos en el conjunto de características correcto durante el desarrollo. ¿Es esto realmente una sugerencia que cree que ayuda a lograr esos objetivos, o está escalando la colina de otra persona?

Estoy teniendo una situación similar a la descrita por @gaearon : recibo advertencias sobre dependencias de que ellos mismos usan dependencias más antiguas y supongo que simplemente no se han actualizado.

Cuando ejecuto yarn upgrade obtengo esto al principio:

warning gulp > vinyl-fs > glob-stream > [email protected] ...
warning gulp > vinyl-fs > glob-watcher > gaze > globule > [email protected] ...
warning gulp > vinyl-fs > glob-watcher > gaze > globule > glob > [email protected] ...

Pero cuando miro la lista que sigue, esas dependencias están actualizadas.

Estoy de acuerdo con @gaearon , ver una advertencia es un poco aterrador, especialmente para mí, ya que soy relativamente nuevo en el uso de Node y he migrado de usar npm a Yarn. Pero también es un poco _engañoso_ ver un mensaje de advertencia, ya que implica que es algo que puedo solucionar.

En mi opinión, creo que estas advertencias deberían convertirse en información amigable o simplemente no deberían mostrarse en absoluto.

Sin embargo, el uso de dependencias inseguras debería dar una advertencia.

Por qué estamos hablando de _scary_. Esto es desarrollo de software, no jardín de infantes.

@wtgtybhertgeghgtwtg Lo que me a) no es _mi_ culpa, el error no es mío yb) adónde ir para ver si se ha abordado el problema. Ese tipo de información puede evitar que los usuarios caigan en la madriguera de tratar de averiguar qué les pasa.

Buena idea para mejorar el mensaje primero, envíe un PR

El 7 de julio de 2017 a las 14:08, Daniel Blake [email protected] escribió:

@wtgtybhertgeghgtwtg https://github.com/wtgtybhertgeghgtwtg Qué arroja
me es que la advertencia me pide que actualice algo que no puedo actualizar.
Aunque, en este caso, no soy yo el que usa la dependencia insegura (yo
creo que Glob es), veo su punto y estoy de acuerdo en que debería ser una advertencia; pero yo
Creo que se puede redactar para que sea más informativo. Algo tan simple como
"[dependency_A] está usando una [dependency_B] obsoleta". Lo sabré de inmediato.
el murciélago que a) no es mi culpa, el error no es de mi parte, y
b) adónde ir para ver si se ha abordado el problema. Ese tipo de
la información puede evitar que los usuarios caigan en la madriguera de intentar averiguar
lo que está mal en su extremo.

-
Recibe esto porque modificó el estado de apertura / cierre.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/yarnpkg/yarn/issues/3738#issuecomment-313793331 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/ACBdWI1Ks6bSYH_BStzm_b3-ne3bUMT3ks5sLp5PgaJpZM4OGrsi
.

Lo que me lanza es que la advertencia me pide que actualice algo que no puedo actualizar.

Si está utilizando una dependencia, seguramente la posee y todo lo que genera, y tiene la capacidad de bifurcar y mejorar lo que sea que la acompañe. Si te molesta, quizás no valga la pena usarlo.

Mientras yo diría que

warning gulp > vinyl-fs > glob-stream > [email protected] ...
warning gulp > vinyl-fs > glob-watcher > gaze > globule > [email protected] ...
warning gulp > vinyl-fs > glob-watcher > gaze > globule > glob > [email protected] ...

le dice lo que necesita saber, estoy de acuerdo en que podría estar redactado de una manera que lo resuma un poco mejor.

¿Podemos mantener este tema centrado en un caso en particular, por favor? No quiero que esto se convierta en un cobertizo de bicicletas sobre todas las posibles advertencias.

Informé de una advertencia específica donde "arreglar" el problema es imposible en principio, ni siquiera en las dependencias transitivas. Todo funciona según lo previsto.

Otros casos descritos en este número muestran problemas legítimos que deben informarse y solucionarse mediante dependencias transitivas. No creo que esto sea similar al problema que describí. Si está muy convencido de ellos, presente un nuevo problema.

No quiero que esto se convierta en un cobertizo de bicicletas sobre todas las posibles advertencias.

Si está relacionado, la conversación probablemente debería ir aquí. Tenga en cuenta la cantidad de problemas abiertos y que esta es una solicitud de mejora y no un error.

Suena bien. Me daré de baja, pero espero que esta discusión se mantenga enfocada en el futuro. ¡Gracias por participar!

Mantenedores, por favor cierren esto. No hay nadie a quien seguir.

¿Podría proporcionar dos casos de prueba gratuitos, por favor?

Hay muchas cosas geniales que se pueden hacer con hilo si mantiene sus ojos en el conjunto de características correcto durante el desarrollo.

Tenga en cuenta la cantidad de problemas abiertos y que esta es una solicitud de mejora y no un error.

Mantenedores, por favor cierren esto.

@jhabdas , agradezco su esfuerzo por hacer que contribuya más de mi tiempo a este tema, y ​​señalando que el equipo de Yarn tiene suficiente en su plato, pero no hay necesidad de seguir reiterando esto. Este no es un comportamiento muy amistoso.

Pido disculpas pero como ya dije antes, realmente no puedo dedicar tiempo a este tema. Confío en que los mantenedores de Yarn tomen las decisiones correctas en la priorización. Si piensan que el problema tiene una prioridad demasiado baja, lo ignorarán o cerrarán con razón.

Por favor, perdóneme si no entiendo bien y está involucrado en el mantenimiento de este repositorio. En este caso, no dude en cerrar este problema.

Pero me gustaría asimilar personalmente lo que consideras una experiencia aterradora para los principiantes por algo que "casi nunca es procesable".

Instalar create-react-app y luego ejecutar create-react-app myapp producirá una advertencia como parte de la instalación:

warning [email protected]: The platform "win32" is incompatible with this module.
info "[email protected]" is an optional dependency and failed compatibility check. Excluding it from installation.

La advertencia de npm es aún más aterradora:

npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules/react-scripts/node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@^1.0.0 (node_modules/react-scripts/node_modules/chokidar/node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})

Afortunadamente, npm nos permite especificar el nivel de registro, lo que Yarn no hace. Desafortunadamente, tenemos que ignorar todas las advertencias de npm debido a esto.

¿Por qué es un problema esta advertencia?

Para un usuario experimentado como tú, no es un problema. Pero la aplicación Create React es el punto de entrada al ecosistema React y npm para muchas personas. Para algunas personas, es un punto de entrada al desarrollo web.

No saben qué es fsevents . El mensaje dice que la aplicación Create React es incompatible con Windows. Esta es su comida para llevar. Es genial si todo funciona más tarde, pero si algo se rompe, no siempre informan un problema porque tienen la idea de que se supone que no funciona gracias a estas advertencias. Estoy tratando de combatir esta impresión con esta propuesta.

¿Por qué estamos hablando de miedo? Esto es desarrollo de software, no jardín de infantes.

La suposición de que la gente solo se asusta en el jardín de infancia me deja perpleja. Hay muchas cosas que le dan miedo a la gente a lo largo de su vida. Esto incluye tanto condiciones mentales como la ansiedad como otros miedos (por ejemplo, miedo a no ser lo suficientemente bueno en su trabajo).

Puede parecer que no está relacionado con las herramientas de JavaScript, pero en realidad no lo es. Aquí hay dos problemas separados:

1. Las advertencias poco claras e inaccesibles provocan ansiedad en las personas. Les hacen confiar menos en sus herramientas y les confunden si hicieron algo mal incluso si no lo hicieron. Esto está contribuyendo al drenaje cognitivo descrito tan bien por Kathy Sierra .

2. El ruido de advertencia inactivo hace que las personas desarrollen un punto ciego para las advertencias. La gente aprende a ignorarlos. Cada advertencia inaccesible contribuye a este costo. Hemos visto suceder muchas veces con diferentes herramientas, no solo con Yarn. Es el escenario del “niño que lloró lobo”. Como resultado, en el futuro, las personas no diagnosticarán problemas y gastarán su tiempo y el de los mantenedores porque se perdieron una advertencia importante en el mar de las sin importancia.

Espero que esto aclare por qué creo que vale la pena abordarlo. Sin embargo, no participaré más en esta discusión porque parece que le apasiona mucho rechazar esta propuesta y no estoy dispuesto a invertir más energía personal en discutirla con usted.

Esta es la profundidad de la información que esperaba extraer de @gaearon. Gracias por tomarse el tiempo para explicar, ya que parece que su empatía por el alumno está brillando y eso es loable.

Siento que es importante que enseñemos a los alumnos a pescar por sí mismos. Y a veces eso significa no protegerlos de sus miedos, sino alentarlos a enfrentar el miedo de frente.

En el caso de una advertencia fsevents , incluso como una dependencia opcional, se debe alentar a los alumnos a observar la advertencia y tratar de comprenderla. De lo contrario, no crecerán.

Una búsqueda rápida de Stack Overflow, por ejemplo, presenta la siguiente solución para manejar el mensaje de advertencia descrito: https://stackoverflow.com/a/42938398/712334.

Si la sobrecarga cognitiva se convierte en una preocupación, entonces animo a una persona a buscar una herramienta diferente para crear sus aplicaciones de una sola página o comenzar su viaje de conocimiento en algún lugar más adecuado para obtener los fundamentos de la Web.

@ glen-84, ¿le gustaría compartir su opinión o simplemente hablar?

Por supuesto.

• Mostrar una advertencia sobre algo que no es procesable y no causa ningún problema da como resultado:
  
  
  
  • Tiempo perdido porque los desarrolladores primero tienen que averiguar por qué está sucediendo y luego tienen que ignorarlo cada vez (e ignorar las advertencias es algo malo)
  
  
  • Tiempo perdido por los desarrolladores de Yarn / npm, teniendo que explicar por qué sucede
  
  
  • Errores de herramientas aguas abajo
  
  
  • etc.
  
  
• Si combina los votos de la edición npm, casi 150 usuarios están de acuerdo.
• Los desarrolladores de npm ya han

He votado en contra de dos de sus comentarios porque, en mi opinión, no añaden valor a esta discusión.

Estoy de acuerdo en que las advertencias que no son procesables no son útiles y también pueden ser innecesariamente aterradoras / ruidosas /. Vamos con @dmbdesignpdx 's sugerencia en cuanto @bestander sugirió?

PR es bienvenida.

Tiempo perdido porque los desarrolladores primero tienen que averiguar por qué está sucediendo y luego tienen que ignorarlo cada vez (e ignorar las advertencias es algo malo)

No lo ignores. Aprende por qué está sucediendo y actúa. A veces, eso conducirá a otro conjunto de herramientas o un problema en el repositorio que aborda la causa raíz como lo sugiere @Vanuan en el problema de NPM relacionado.

Tiempo perdido por los desarrolladores de Yarn / npm, teniendo que explicar por qué sucede

No es responsabilidad de Yarn abordar problemas de repositorios individuales o administradores de paquetes. Y NPM no es el único empaquetador que existe. Y personalmente preferiría ver crecer a Yarn para reemplazar a Composer y llenar el vacío que Bower acaba de dejar en la comunidad en lugar de distraerme con pistas falsas.

Si combina los votos de la edición npm, casi 150 usuarios están de acuerdo.

Eso es argumentum ad populum. El diseño por comité nunca funciona bien para nadie.

Se eliminó la etiqueta cat-discusson desde que tuvimos nuestra discusión y ahora tenemos algo que hacer: hacer que la advertencia sea más útil indicando qué paquete depende de ese otro paquete obsoleto.

@jhabdas Creo que estamos de acuerdo en las partes de "aprender" y "actuar". La parte en la que parecemos no estar demasiado de acuerdo es en cómo lo hacemos y si es yarn s deber o no. Por ahora, creo que cuanto más útil sea el hilo para sus usuarios, mejor será. Dicho esto, no le daría mucha prioridad a esto para quitarle recursos a las correcciones y actualizaciones más críticas, por lo que nos remitimos a la comunidad para obtener un PR.

Si alguien quiere discutir más sobre este tema, pasemos a Discord. Puede enviarme un ping directamente para llamar mi atención. 💓

Aprende por qué está sucediendo y actúa

¿Qué acción debemos tomar?

No es responsabilidad de Yarn abordar problemas de repositorios individuales o administradores de paquetes.

Son los desarrolladores de Yarn y npm quienes verán problemas reportados repetidamente con respecto a este asunto, y tendrán que dedicar tiempo a la clasificación de problemas innecesarios en lugar de trabajar en nuevas funciones y correcciones de errores.

Eso es argumentum ad populum. El diseño por comité nunca funciona bien para nadie.

Es todo lo que tenemos en este momento, y si no está de acuerdo con estos cambios, su voto negativo sobre el tema ayudaría a los mantenedores con su toma de decisiones.

De acuerdo, @ glen-84 me recordó amablemente que el problema original no se refería a las subdependencias y los mensajes informativos, sino simplemente a no advertir sobre un paquete que no se puede instalar en una plataforma específica.

Entonces, ahora la acción para este ticket específico es simplemente reducirlo de una advertencia a información o depuración, ya que no agrega valor. Objeciones Moví la otra parte al # 3869.

@gaearon Se realizó un cambio de código de una línea sin prueba unitaria para resolver este problema. Por favor recuerde eso.

@jhabdas ya respondí en el PR. Esta es mi filosofía https://stackoverflow.com/questions/153234/how-deep-are-your-unit-tests/153565#153565, pero si cree que la compatibilidad del paquete o esa parte en particular necesita algunas pruebas, por favor abra una solicitud de extracción y gracias de antemano :)

Confío en tu buen juicio, pero confío tanto como puedo lanzar una ramita. Pero eso está bien. Quería enviar mi mensaje en beneficio de otros para ver cómo un cambio de código de una línea podría haber evitado todo este hilo. A veces, las acciones hablan más que las palabras. Salud.

@jhabdas por mucho que aprecio sus contribuciones, me gustaría recordarle nuestro código de conducta , específicamente los siguientes puntos:

• Usar un lenguaje acogedor e inclusivo
• Respetar los diferentes puntos de vista y experiencias.
• Mostrar empatía hacia otros miembros de la comunidad

Mis más sinceras disculpas. Revisaré el código de conducta y trataré de ser un buen ciudadano de la comunidad. Gracias por señalarme en la dirección correcta, @BYK.

Gracias por arreglar esto. 😍 🙇

Fue el tema más votado en NPM por un amplio margen y causó problemas reales, sin embargo, después de 1,5 años de no abordarlo, ¡su bot simplemente lo cerró automáticamente por ser demasiado viejo!

Ese tipo de gestión de proyectos es una de las razones por las que me cambié a Yarn.

Al ver lo fácil que fue la solución, es angustioso cuánto tiempo y esfuerzo se desperdició en esto. 😢

¡Gracias!

Hola, gracias por todos los esfuerzos al respecto. Es mucho mejor que ahora esté en mi stdout en lugar de stderror;). Sin embargo, incluso el nivel de información traerá aquí toneladas de personas. Y el único resultado que obtendrán después de una hora de leer los problemas relacionados es que necesitan vivir con eso por el momento (quién no usa babel) y que es posible realizar una optimización específica de la plataforma a través de dependencias opcionales, pero con un costo de los administradores de paquetes advierten al usuario. Estoy en el lado de tener esto generado solo a nivel de depuración.

@kubino, es un gran comentario, ¡gracias! Somos conscientes de que moverlo a info no lo solucionaría de una vez por todas. Por eso, @jhabdas realmente dedicó un tiempo a hacerlo aún mejor y genérico y envió un RFC . ¿Le interesaría enviarnos sus comentarios y hacernos saber si ese RFC aborda sus inquietudes?

@BYK gracias por seguir interesado en esto. Estoy lejos de ser un experto y quizás me equivoqué. Me estás indicando RFC donde el título es "hacer que las advertencias de los subpaquetes obsoletos sean más informativas". Creo que entregar advertencias DEPRECATED a los usuarios es correcto por defecto (aunque probablemente sería bueno tener una forma de suprimir advertencias de paquetes en particular).
Mi preocupación eran las dependencias OPCIONALES que solo sirven como optimización para alguna plataforma de concreto, allí veo muy poco valor de contaminar, de otra manera, una salida de hilo tan hermosa y limpia. Pero como dije, no soy un experto y no estoy seguro de si esto siempre es tan claro para determinar

@kubino no hace falta ser un experto. Sabes que el mundo está lleno de expertos autoproclamados, así que es mejor afirmar que no eres un experto y es posible que termines siendo uno 😀

De todos modos, todavía no he tenido tiempo de leer ese RFC por completo, pero creo que se incluye en la sección label = "Interoperability" . Dicho esto, quizás deberíamos agregar una sección optimization para estos casos. Dicho esto, continuemos la discusión sobre ese RP y creo que debería hacer esta sugerencia allí y ver qué piensa @jhabdas al respecto.

@kubino He actualizado la descripción de

El RFC es una propuesta para tratar de ayudar a abordar una serie de casos de uso relacionados que pueden aparecer al introducir una característica pequeña (aparentemente no relacionada) que, cuando se usa de manera creativa, tiene la intención de ayudar a satisfacer necesidades como las que ha planteado al mismo tiempo. agregando un beneficio adicional al gran trabajo que Yarn ya ha logrado para la comunidad.

Siéntase feliz de discutir y utilizar sus conocimientos para mejorar aún más el RFC, ya que he aprendido que tener más experiencia puede ser tanto o más una responsabilidad como una ventaja cuando se trata de codificación.

@BYK Sé a dónde @jhabdas , la solución genérica es la única salida a estas discusiones. La categorización de mensajes es el primer paso que permitirá todo lo demás ... continuemos la discusión en el RFC relacionado. ¡Gracias!

Si es opcional "dado un sistema operativo de destino", entonces ni siquiera debería ser el nivel WARN. El autor dice "Si MacOS usa FSEvents, de lo contrario no lo haga". Entonces, si está instalando en un sistema operativo que no sea Mac, ¿por qué advertir? Es más como información / depuración.

@robertjchristian Creo que hay dos aspectos en esto:

1. fsevents sí mismo no funciona fuera de macOS, por lo que un intento de instalarlo en dicho sistema operativo debería mostrar una advertencia o un error. Algunos paquetes que usan fsevents pueden depender de su API universalmente (incorrectamente) sin saber que son solo para macOS y que se rompen en otros sistemas operativos en el proceso.
2. Si fsevents es para algunos paquetes necesarios solo en macOS, esos paquetes deberían poder marcar fsevents como no para ser instalado fuera de macOS. Si no se instala fsevents en macOS, se produciría una falla, pero en otros sistemas operativos ni siquiera habría un intento de instalación.

El problema principal es que tratar fsevents como una dependencia opcional es un enfoque incorrecto. Lo que falta es la capacidad de marcar fsevents como se requiere en macOS y como completamente excluido, no solo opcional, en otros sistemas operativos.

Sí, eso se explicó varias veces en el hilo original, parece que nadie escuchó:

https://github.com/npm/npm/issues/11632#issuecomment -238217690

La solución sería agregar soporte para dependencias específicas de la plataforma.

https://github.com/npm/npm/issues/11632#issuecomment -257214969

la solución 'correcta' es tener algún método de dependencias condicionales, una forma de que un paquete indique que una o más de sus dependencias no deben instalarse en algunas plataformas. Esto no es lo mismo que un paquete que se describe a sí mismo como específico de una plataforma: un paquete no sabe si es opcional o no, por lo que todo lo que puede decir es 'si me instala en la plataforma incorrecta, es un error'.

https://github.com/npm/npm/issues/11632#issuecomment -300804918

Esto es lo que podría hacer npm:

1. Cambie las dependencias opcionales y los mensajes no admitidos de WARN a INFO (lo que la mayoría de la gente quiere).
2. Implementar dependencias específicas de la plataforma (solución adecuada)

Entonces, en lugar de ocultar la advertencia, deberían haberla solucionado correctamente implementando dependencias condicionales. Pero eso requiere cambiar la especificación package.json. Imagino algo como esto:

  "conditionalDependencies": {
    {
      "condition": { "platform": "darwin" }, // 'darwin', 'freebsd', 'linux', 'sunos' or 'win32'
      "packages": { "fsevents": "^1.0.0" }
    }
  },

Otra alternativa es para los siguientes autores:

Haga que no falle en plataformas que no sean OSX sin ninguna advertencia, solo mensaje INFO sobre la plataforma no compatible

Pero eso no es muy diferente de ocultar la advertencia a nivel de npm.

¿Aún sin respuesta? Esa advertencia es tan molesta.

En este punto, estoy tentado a comprar una Mac con el único propósito de no ver esto durante otros cuatro años, aunque detesto el sistema operativo 👎

En este punto, estoy tentado a comprar una Mac con el único propósito de no ver esto durante otros cuatro años, aunque detesto el sistema operativo 👎

Si está desarrollando software de forma profesional, no podría recomendar una mejor inversión.

¿Por qué mostrar una advertencia si no requiere que el usuario haga algo para corregirlo?

Todos discuten para mantener la advertencia, por favor, tomen un segundo para pensar. Si el usuario no puede hacer nada para corregir esta advertencia, ¿por qué la mostramos?

Es como si tu pareja te dijera que tiene hambre, que eres como un cocinero para ti mismo, que no lo harán, que cocinas que no comerán, pero te sigo molestando, tengo hambre. Cada vez que dices hola (npm install / yarn), dicen que tengo hambre (WARN WARN WARN) .. Me parece inútil.

En este punto, estoy tentado a comprar una Mac con el único propósito de no ver esto.

¿Quiere decir que no verá esto en Mac?
Bueno, no lo hará a menos que use la ventana acoplable:

MacbookPro $ docker run -ti --rm node yarn add [email protected]
yarn add v1.13.0
info No lockfile found.
[1/4] Resolving packages...
[2/4] Fetching packages...
info [email protected]: The platform "linux" is incompatible with this module.
info "[email protected]" is an optional dependency and failed compatibility check. Excluding it from installation.

Creo que tendrías mejor suerte bifurcando chokidar y eliminando fsevents de allí.
El nodo reciente tiene grandes mejoras con soporte nativo fs.watch en OS X.

Por supuesto, también tendrías que bifurcar docenas de paquetes dependiendo de chokidar

Intente quejarse aquí para variar:
https://github.com/paulmillr/chokidar/issues

Creo que tendrías mejor suerte bifurcando chokidar y eliminando fsevents de allí.
El nodo reciente tiene grandes mejoras con soporte nativo fs.watch en OS X.

Parece que estamos en la misma página después de todo. xD

Sí, supongo que la única opción es esperar hasta que chokidar deje de admitir el nodo 10, momento en el que se volverá inútil y otros proyectos comenzarán a eliminarlo.

@Vanuan El reciente soporte de node.js para fs.watch sigue siendo una mierda. Intente usarlo en todas las plataformas.

Si desea quejarse de las advertencias de instalación, puede quejarse con los encargados de mantenimiento que "desaprueban" los paquetes. Eso es realmente jodidamente molesto. Esto no sucedió en el pasado. Fsevents es un problema mucho menor en comparación con esto.

¿Esto nunca se solucionará?