Yarn: Los archivos de bloqueo de la competencia crean una mala experiencia de usuario

Agregue config a package.json para indicar

Podría ser un buen caso de uso para el campo engine 🤔

El viaje de ida y vuelta package-lock.json → yarn.lock → package-lock.json tiene pérdidas, pero eso probablemente no sea importante. yarn.lock → package-lock.json → yarn.lock no debe tener pérdidas, AFAIK.

Desde el punto de vista de npm , prefiero la opción en la que si yarn ve un package-lock.json y no un yarn.lock que lo importa y elimina el package-lock.json . Y de manera similar, si npm ve un yarn.lock y no package-lock.json , debería hacer lo mismo, importando y eliminando el `yarn.lock.

Esto permitiría a los usuarios de ambas herramientas cambiar sin problemas de un lado a otro sin dejar el proyecto del usuario en un estado confuso (donde los archivos parecen ser de ambos).

Estoy un poco preocupado con esto, porque significa que ni package-lock.json ni yarn.lock podrán agregar metadatos a los archivos (Yarn actualmente no lo hace, pero por qué no), eliminando algunos libertad a nuestros formatos en el proceso.

Este problema también plantea la cuestión de la interoperabilidad entre Yarn y npm en general, que se discutió originalmente en otro hilo. Siento que tratar de ser demasiado interoperable podría merecernos a los dos, ya que los usuarios tendrán la expectativa de que todo funcionará exactamente de la misma manera. en ambos proyectos, lo que creo que es una suposición peligrosa (un ejemplo obvio es que los espacios de trabajo se romperán silenciosamente si alguien ejecuta npm en un proyecto impulsado por un espacio de trabajo).

@ yarnpkg / core, ¿pensamientos?

Me gusta la idea de @ iarna de hacer que ambas herramientas migren de un archivo de bloqueo a
otro en instalar automáticamente.
Tiene sentido eliminar el archivo de bloqueo importado después de la migración para evitar
Ambos gestores de paquetes compiten en un proyecto.

Ambas herramientas pueden imprimir advertencias y tal vez requieran un aviso del usuario para continuar.

También estoy de acuerdo con el punto de Mael de que lograr el 100% de compatibilidad bloqueará
de explorar nuevas funciones, creo que deberíamos tratarlo como algo único
ruta de migración, que podría ser una característica bastante pequeña en install.js en nuestro
lado.

El miércoles 11 de abril de 2018 a las 9:49 p.m., Maël Nison [email protected] escribió:

Estoy un poco preocupado por esto, porque significa que ni
package-lock.json ni yarn.lock podrán agregar metadatos a los archivos
(Yarn actualmente no lo hace, pero por qué no), quitando algo de libertad a nuestros formatos
en el proceso.

Este problema también plantea la cuestión de la interoperabilidad entre Yarn y
npm en general, originalmente discutido en otro hilo - tengo ganas de intentar
ser demasiado interoperable podría merecernos a los dos, ya que los usuarios
tener la expectativa de que todo funcionará exactamente de la misma manera en ambos
proyecto, que creo que es una suposición peligrosa (un ejemplo obvio es
que los espacios de trabajo se romperán silenciosamente si alguien ejecuta npm en un
proyecto impulsado por el espacio de trabajo).

@ yarnpkg / core https://github.com/orgs/yarnpkg/teams/core , ¿pensamientos?

-
Recibes esto porque estás en un equipo que se mencionó.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/yarnpkg/yarn/issues/5654#issuecomment-380677110 , o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/ACBdWI9jnLJeFqH8v2T-AB74sQO1PMIjks5tntzrgaJpZM4TQ5-B
.

Haciendo ping a

¡Gracias por el ping!

Así que sí, en realidad estoy trabajando exactamente en esto. Estaba planeando escribir un RFC de hilo y hacer ping a todos los interesados ​​la próxima semana.

En resumen: he trabajado un poco para convertir yarn.lock <==> package-lock.json. Hay algunas pérdidas en el proceso, pero muy pocas de ellas son lógicas. En mi opinión, esto es totalmente aceptable si estamos hablando del escenario de 'conversión única' mencionado anteriormente. Si quisiéramos discutir esto más a fondo, puedo entrar en más detalles.

Actualmente tengo un código rudimentario que hace esto: https://github.com/imsnif/synp
No es 100% y se basa en una carpeta node_modules existente y actual para que el proyecto se convierta. Estoy en las etapas finales de una reescritura (en la rama 2.0.0 ) que obtendrá el estado del paquete del registro (usando el increíble pacote lib).

Lo que quiero hacer una vez hecho esto es comenzar a hablar sobre cómo (¿y si?) Nos gustaría implementar esto exactamente en yarn y npm .

Me encantaría escuchar los pensamientos de todos sobre esto.

En mi opinión, esto es totalmente aceptable si estamos hablando del escenario de 'conversión única' mencionado anteriormente.

No creo que sea tan común. Puede que esté equivocado, pero siento que el caso de uso más común serán los proyectos que usan Yarn, y uno de los desarrolladores copia / pega el comando de un README para agregar una dependencia, usando npm lugar de yarn en el proceso.

En este contexto, todavía no estoy convencido de que sea bueno perder datos y cambiar el diseño del paquete en silencio tratando de hacer lo correcto; probablemente ni siquiera lo notarán hasta que las cosas se rompan (podríamos tener un mensaje de confirmación, pero Espero que la gente que copie / pegue esos comandos también confirme ciegamente las indicaciones de instalación). Peor aún, podría funcionar en su propia máquina, pero romperse en las de sus colegas una vez que regresen a Yarn.

@arcanis - Creo que vale la pena discutir todos los escenarios y casos

Veo que esta característica se usa principalmente en entornos de CI, donde creo que puede brillar (como OP mencionó). Sin embargo, como mínimo, creo que ambas herramientas deberían conocer el archivo de bloqueo de la otra herramienta. Dejando a ellos los detalles de cuándo deciden realizar la conversión. ¿Qué piensas?

Veo que esta característica se usa principalmente en entornos de CI, donde creo que puede brillar (como OP mencionó).

¿Tienes un ejemplo? Se supone que los sistemas de CI actúan de una manera muy determinista, cometer accidentalmente un archivo de bloqueo convertido es algo que debería cogerse peor en el tiempo de PR, en mi opinión, CI es demasiado tarde para esto.

Sin embargo, como mínimo, creo que ambas herramientas deberían conocer el archivo de bloqueo de la otra herramienta.

Tal vez. Usando la versión engine para forzar que un administrador de paquetes específico me parezca más limpio, ambos proyectos solo tendrían que mantener una lista de motores exclusivos (como "yarn" no se puede satisfacer en "npm", y viceversa).

En mi opinión, convertir los archivos de bloqueo sobre la marcha tampoco es muy escalable. Por ejemplo, solo hemos estado hablando del archivo package-lock.json hasta ahora, pero creo que pnpm tiene su propio archivo de bloqueo llamado shrinkwrap.yaml . Sería bueno que pudiéramos encontrar una manera de lidiar con ambos y con cualquier otro formato que pudiera surgir con una piedra.

Veo que esta característica se usa principalmente en entornos de CI, donde creo que puede brillar (como OP mencionó).

También tenga en cuenta que si entendí correctamente, npm está trabajando actualmente en un administrador de paquetes muy ligero específico de CI, que podría no funcionar muy bien con cosas que requieren una lógica comercial pesada, como un convertidor de archivos de bloqueo.

Respecto a CI:
Mi pensamiento inicial fue: advertir cuando agregue un nuevo paquete con la herramienta opuesta, convertir al hacer una instalación nueva (o más conservadoramente: fallar de forma predeterminada en una instalación nueva y permitir la conversión detalladamente a través de un comando import o una marca de configuración para instalar).

Cuando trabajé anteriormente en un entorno mixto npm / yarn, básicamente lo haríamos manualmente con historiales de git. Fue un proceso laborioso y estoy seguro de que estuvimos / no estamos solos en esto.

En cuanto a escalabilidad:
Me gustaría dar cuenta de esto también.
Cuando se realiza la conversión, se crea un árbol de paquetes lógico y físico intermedio (si el archivo de bloqueo tiene uno). Al convertir al archivo de bloqueo deseado, esos árboles se utilizan (o se crean con valores predeterminados adecuados en caso de que estemos convirtiendo de yarn y no tengamos un árbol físico).
De esta manera, podemos convertir fácilmente entre otros tipos de archivos de bloqueo como (todo lo que tenemos que hacer es proporcionar conversiones a / desde un árbol lógico / físico para cada tipo).

Obviamente, esto está un poco por delante de las capacidades de la herramienta en este momento, pero no veo la implementación de esto como un gran problema.

(en cuanto a la nueva herramienta ci de npm, veo lo que quieres decir, pero creo que esto está un poco por delante de la discusión actual)

o de manera más conservadora: falla de forma predeterminada en una instalación nueva y permite verbosamente la conversión a través de un comando de importación

Sí, estaría totalmente a favor de agregar esta lógica de conversión en el comando yarn import , parece una característica útil que se puede extraer en un paquete separado si / cuando logramos implementar los complementos de Yarn :) Mis comentarios son centrándose en el comportamiento predeterminado que debemos adoptar.

A partir de npm@6 , debería poder convertir package-lock.json -> yarn.lock sin pérdidas, sin tener que ejecutar una instalación primero. Debe contener todos los datos que necesita, identificadores, etc. (el pkglock de npm @ 6 tiene rangos de versión en el campo requires , que coincide con lo que usa yarn.lock ?)

Ah, y también necesita que https://github.com/yarnpkg/yarn/pull/5042 se envíe antes de que esto sea cierto, ya que npm no tiene sha1 en el pkglock en muchos casos.

@arcanis - ¡fantástico! También lo haría un PR con:

1. Una advertencia al instalar y encontrar un archivo package-lock.json
2. Una advertencia al agregar y encontrar un archivo package-lock.json
3. Agregar la capacidad de convertir desde package-lock.json través del comando import (y eliminar el archivo a partir de entonces)
   ¿Estar bien visto? (solo para que tengamos algo que podamos usar para comenzar la conversación sobre detalles)

@zkat - ¡eso es genial sobre npm@6 ! Si depende de mí, optaría por usar eso y recurrir a los archivos de manifiesto para admitir todas las versiones de archivos de bloqueo. ¿Podría preguntarle si estaría dispuesto a implementar un comportamiento similar (o quizás algo diferente) por npm ?

También tenga en cuenta que si entendí correctamente, npm está trabajando actualmente en un administrador de paquetes muy ligero específico de CI, que podría no funcionar muy bien con cosas que requieren una lógica comercial pesada, como un convertidor de archivos de bloqueo.

Si por "actualmente trabajando en" te refieres a "han enviado", entonces sí. =)

Como sugiere, actualmente cargar yarn.locks está más allá de su alcance (ya que no sabe cómo diseñar árboles de paquetes) pero si todos terminamos con una biblioteca que puede hacer ese diseño, no me opongo a que admita la carga candados de hilo. (Idealmente, esta sería una biblioteca compartida entre él y Yarn). Obviamente, para su caso, no debería eliminar el archivo de bloqueo existente. Es puramente de solo lectura en lo que respecta a los metadatos del paquete.

Una advertencia al instalar y encontrar un archivo package-lock.json

Me preocupa que el simple hecho de tener advertencias cuando existe un tipo de archivo de bloqueo no compatible no ayudará con los problemas planteados por @jmorrell que está teniendo Heroku.

Me preocupa que el simple hecho de tener advertencias cuando existe un tipo de archivo de bloqueo no compatible no ayudará con los problemas planteados por @jmorrell que está teniendo Heroku.

Una advertencia sería una mejora, pero un error con una buena mensajería sería ideal para los usuarios en mi opinión. Solo puedo hablar por mí mismo, pero tengo varios proyectos, algunos que usan hilo y otros que usan npm, y a menudo me encuentro escribiendo el incorrecto para ese proyecto. Un error rápido significa que puedo usar inmediatamente el que debería tener desde el principio.

Si es una advertencia, debería ser grande y obvia. Los usuarios de IME están bastante entrenados para esperar ignorar la salida de su administrador de paquetes siempre que funcione.

Me comuniqué con algunas personas que tienen más experiencia con los desarrolladores principiantes y que, con suerte, se comunicarán con la experiencia de alguien que recién comienza.

Se supone que los sistemas de CI actúan de una manera muy determinista, cometer accidentalmente un archivo de bloqueo convertido es algo que debería cogerse peor en el tiempo de PR, en mi opinión, CI es demasiado tarde para esto.

Estoy de acuerdo. Idealmente, cuando llega al servicio de compilación / CI, la aplicación no se encuentra en un estado indeterminado. La única forma en que me sentiría cómodo no fallando en la compilación en este caso era si hubiera una forma aceptada para que el usuario indicara su preferencia en package.json , pero esa solución también supone más carga para el usuario.

Me preocupa que el simple hecho de tener advertencias cuando existe un tipo de archivo de bloqueo no compatible no ayudará con los problemas planteados por @jmorrell que está teniendo Heroku.

Les ayudaría advirtiéndoles a los usuarios que están haciendo algo que probablemente no quieran antes de presionar a Heroku. No estoy seguro de cuánto cambiaría realmente los números, pero eso es algo que podemos verificar en unas pocas semanas y ver si necesitamos ir más allá. Y dado que los cambios necesarios son relativamente pequeños, esa podría ser una buena primera iteración.

Pregunta honesta para quienes proponen una advertencia: ¿Existe una situación en la que ejecutar yarn install o yarn add mientras un package-lock.json está presente no sería un error? Lo mismo ocurre con npm install y yarn.lock

Me viene a la mente la migración de npm a Yarn, o de Yarn a npm. Preferiría evitar agregar fricciones cuando uno quiere probar otros administradores de paquetes.

Una cosa a tener en cuenta también es que las advertencias y los errores no son mutuamente excluyentes, o al menos no con el campo engine . Los proyectos sin administradores de paquetes anclados podrían imprimir una advertencia y los proyectos con un administrador de paquetes anclados podrían generar errores. De esta manera, los usuarios pueden cambiar libremente de un administrador de paquetes a otro, hasta que hagan su elección y configuren su package.json en consecuencia.

Otra ventaja del campo del motor es que le permitiría saber con certeza qué versión del administrador de paquetes debe usarse. Supongo que se puede configurar en algún lugar, pero con este sistema sería parte del flujo de trabajo normal.

Otra ventaja del campo del motor es que le permitiría saber con certeza qué versión del administrador de paquetes debe usarse. Supongo que se puede configurar en algún lugar, pero con este sistema sería parte del flujo de trabajo normal.

¿Hay un campo engine o se refiere a engines ? No encuentro ningún documento que haga referencia a engine . Disculpas si me estoy perdiendo algo.

Admitimos especificar versiones en el campo engines : https://devcenter.heroku.com/articles/nodejs-support#specifying -an-npm-version

Ex:

  "engines": {
    "npm": "5.6.x"
  }

Hay un par de preocupaciones que tengo al usar esto para determinar qué administrador de paquetes usar:

• La forma en que se ven las cosas hoy: un número no trivial de usuarios tiene definidos npm y yarn , o una versión npm, pero luego tienen un yarn.lock . Las versiones futuras de npm y yarn podrían hacer cumplir esto, pero los usuarios que no actualicen con frecuencia continuarán usando las versiones actuales durante mucho tiempo.

• La mayoría de los usuarios nunca tocan esta configuración. Bifurcaron una vieja placa de calderas que especificaba el nodo 0.10 a pesar de que usan lo que hayan descargado de nodejs.org en su máquina. Esto causa una cantidad no trivial de problemas en Heroku.

• Los equipos a menudo no coordinan qué versiones han instalado. La versión de Node o npm o yarn que han instalado es a menudo la que estaba vigente cuando comenzaron un proyecto o la última vez que uno de ellos se rompió y los obligó a reinstalar. No es que esto sea ideal, pero tengo entendido que la mayoría de los usuarios de npm / yarn son principiantes, y esto agrega un nuevo obstáculo para comenzar.

Ejemplo: "Cloné el proyecto de ejemplo hello-world, descargué Node de https://nodejs.org y no funcionó"

Dicho todo esto, me encantaría , me engines . Evitaría muchos de los errores que veo todos los días, pero se siente como un cambio mucho, mucho mayor.

Dicho todo esto, me encantaría, me encantaría, me encantaría que las herramientas aplicaran versiones estrictas y lo registraran en los motores. Evitaría muchos de los errores que veo todos los días, pero se siente como un cambio mucho, mucho mayor.

AFAIK Yarn aplica este campo estrictamente a menos que pase una bandera para deshabilitarlo.

Los equipos a menudo no coordinan qué versiones han instalado. La versión de Node o npm o yarn que han instalado es a menudo la que estaba vigente cuando comenzaron un proyecto o la última vez que uno de ellos se rompió y los obligó a reinstalar.

Esto es bastante peligroso, especialmente cuando se usa Yarn, ya que solo garantiza la coherencia en las mismas versiones principales de Yarn.

No es que esto sea ideal, pero tengo entendido que la mayoría de los usuarios de npm / yarn son principiantes, y esto agrega un nuevo obstáculo para comenzar.

¿Qué tal Yarn (y también npm, si les gusta la idea) agregando una entrada "yarn": "^<current_version>" en el campo engines para ayudar a introducir algo de seguridad sin demasiada fricción? Podemos agregar esto automáticamente cuando ejecutamos yarn init , yarn import o cuando creamos un archivo de bloqueo desde cero.

No sé mucho sobre Yarn, pero creo que la mejor solución sería agregar un analizador package-lock.json en Yarn y no crear un yarn.lock si existe.

Creo que el objetivo final debería ser tener un formato de archivo de bloqueo compartido entre Yarn y npm.

@thatlittlegit Entonces le complacerá saber acerca de https://github.com/yarnpkg/yarn/pull/5745 . (npm hará lo mismo a la inversa, por lo que terminaremos en un lugar donde no importa desde qué tipo de archivo de bloqueo esté trabajando o qué herramienta elija).

Editado para agregar: Creo que un solo formato de archivo de bloqueo no es un resultado probable, ya que existen diferentes compensaciones entre los formatos de archivo de bloqueo y la falta de consenso sobre cuál es el mejor. Creo que es suficiente que ambas herramientas puedan comprender mutuamente los archivos de bloqueo de la otra.

Más allá de eso, hay un montón de ventajas de tener múltiples herramientas de uso activo que hacen diferentes compensaciones porque significa que los casos de uso de los usuarios se pueden cumplir mejor que con una única solución general.

@BYK Es probable que algún historial sobre el comportamiento del campo del motor sea útil aquí:

En npm @ 1 y npm @ 2 , teníamos un package.json llamado engineStrict además de los campos engine . Si engineStrict fuera verdadero, entonces el campo del motor se usó como _restricción de resolución_ y antes de aplicar el rango de semver a la lista de versiones, se filtrarían las versiones con motores incompatibles. Esto le permitiría hacer cosas como npm install foo y obtener [email protected] incluso si [email protected] se publicó si [email protected] no fuera compatible con su plataforma. Esto _ parece_ deseable, pero en la práctica fue muy confuso, particularmente porque los documentos en el sitio web eran solo para la versión más reciente.

Si engineStrict eran falsos, la resolución se realizaba sin tener en cuenta los campos del motor y se emitían advertencias si el resultado no era compatible.

TAMBIÉN había una opción de configuración engine-strict , que hacía lo mismo que la propiedad package.json , pero la aplicaba a TODOS los paquetes.

A partir de npm @ 3 , dejamos de admitir la propiedad engineStrict package.json y cambiamos el comportamiento de la opción engine-strict config. La opción de configuración ahora convierte las advertencias que recibe con ella en errores, pero no afecta la resolución.

Los campos engine se aplican no solo para el proyecto de nivel superior, sino también de forma transitiva. La introducción de una bandera de motor yarn implicaría que las dependencias solo se pueden instalar con hilo y no creo que ese sea el caso aquí.

Dado que en el próximo lanzamiento de yarn deberíamos tener la capacidad de importar package-lock.json a yarn.lock , me gustaría volver a discutir el problema de advertencia / error.

A mi modo de ver: no creo que haya una buena razón para que un solo paquete tenga un archivo package-lock.json y yarn.lock . La mayoría de los proyectos que he visto que tienen esto, a sabiendas, lo ven como un problema que debe solucionarse en lugar de una situación deseada (pero, por supuesto, estoy abierto a ser corregido).
Como entiendo por la explicación de @iarna anterior, el campo engine no será una buena solución para especificar explícitamente qué administrador de paquetes está usando un paquete.
Entonces, en mi opinión, esta es una situación que debería producir un error detallado que invitaría al usuario a eliminar un archivo o convertirlo.

Sin embargo, creo que producir tal error sería un claro cambio radical. En el lado del hilo, propondría comenzar con una advertencia (como se mencionó anteriormente) y desaprobar lentamente este comportamiento hasta la próxima versión principal en la que se cambiaría a un error (tal vez agregando una bandera de configuración que permitiría que ambos archivos existen simultáneamente).

¿Qué piensan todos? @jmorrell , @BYK , @arcanis , @iarna?

Me parece extraño que cualquier tipo de proyecto deba especificar qué herramienta de gestión de paquetes se debe utilizar. Corrígeme si me equivoco, pero veo a Yarn como un reemplazo directo que depende principalmente de las preferencias del usuario final. ¿Yarn está tratando de reemplazar completamente a la NPM como el estándar de facto, o está tratando de coexistir?

@BrainBacon Solo obtiene los beneficios de las dependencias bloqueadas si todos usan el mismo administrador de paquetes que respeta el mismo archivo de bloqueo y usa la misma semántica. Si un proyecto tiene un yarn.lock y luego alguien ejecuta un npm install , esa persona aún podría terminar con un conjunto diferente de dependencias. Entonces, no, no depende de las preferencias del usuario final, desafortunadamente; preferiblemente, todos en un proyecto usan el mismo administrador de paquetes.

Esto también significa que no tiene sentido tener dos archivos de bloqueo en un proyecto. Es poco probable que se resuelvan en el mismo árbol de dependencias y no les quede claro a los colaboradores qué administrador de paquetes usar.

(La parte de reemplazo directa fue especialmente cierta cuando npm no producía archivos de bloqueo, ya que no había información que perderse allí. También es cierto si # 5745 realmente significa que Yarn ahora puede producir un archivo de bloqueo basado en package-lock.json , pero eso solo significa que un _proyecto_ puede reemplazar fácilmente npm por Yarn. Sin embargo, dado que aún necesita verificar el nuevo archivo de bloqueo, todos los colaboradores deberán cambiar)

Corrígeme si me equivoco, pero veo a Yarn como un reemplazo directo que depende principalmente de las preferencias del usuario final.

Yarn no es un reemplazo directo en términos de API expuesta. El yarn add <pkg> vs npm install <pkg> es un ejemplo obvio de algo en el que hacemos las cosas de manera diferente. Tendemos a tener el mismo conjunto de funciones, pero al final son dos herramientas diferentes y, a veces, tenemos diferentes soluciones para un mismo problema.

El yarn.lock vs package-lock.json es una de esas diferencias y creo que ni Yarn ni npm están interesados ​​en usar uno solo, ya que contienen información diferente.

En el lado del hilo, propondría comenzar con una advertencia (como se mencionó anteriormente)

Estaría bien con esto. Algo como:

WARN Your project seem to contain lock files (package-lock.json, shrinkwrap.json) generated
WARN by other tools than Yarn. It is advised not to mix package managers, in order to avoid
WARN resolution inconsistencies caused by desynchronized lock files.

¿Alguien quiere abrir un PR?

Me encantaría abrir un PR que agregue una advertencia :)

¿Es la solución final deseada aquí un error útil cuando package-lock.json existe + yarn import ? Tenía entendido que

Cualquiera de las dos soluciones sería una mejora significativa para los usuarios, pero creo que sería mejor si tanto yarn como npm eligieran la misma estrategia (aunque no es estrictamente necesario si no hay un acuerdo y la gente lo cree firmemente).

@jmorrell : tenía entendido que acordamos que la conversión automática es una mala idea aquí.

Sobre todo porque es difícil saber cuál debería ser el delta entre los dos archivos de bloqueo.
P.ej. cuando veo la advertencia anterior como desarrollador, lo que probablemente querría hacer es averiguar cuándo se creó el otro archivo de bloqueo, qué paquetes se agregaron que no se agregaron a mi archivo de bloqueo principal y luego agregarlos. Tal vez usando la opción import como referencia, pero no necesariamente.

Espero que la gente de npm esté de acuerdo con esto.

Idealmente, me gustaría que la advertencia incluyera algo acerca de que esta es una situación obsoleta (no estoy seguro de la redacción) y que las versiones futuras de hilo producirán un error. Tal vez se vincule a alguna documentación detallada sobre esto y cómo abordarlo. @arcanis : ¿crees que es factible o prefieres quedarte con el comportamiento warning ?

Si ambas herramientas emiten un error cuando hay varios archivos de bloqueo, creo que los desarrolladores se darán cuenta de este problema mientras aún es "pequeño" y podrán solucionarlo rápidamente (con la ayuda de la importación como referencia o sin ella) .

@arcanis npm add <pkg> es perfectamente válido y hace lo que hace Yarn 👼

En cuanto a pkglock vs yarnlock, la intención original de package-lock.json era crear un formato que incluyera todos los datos que cualquier administrador de paquetes necesitaba. De hecho, pkglock a partir de npm@6 se puede convertir de forma transparente en yarn.lock sin ejecutar un instalador, ya que describe un árbol completo con todos los metadatos relevantes. Hicimos eso _intencionalmente_ (como el campo requires ), y pedimos comentarios de los equipos de Yarn y pnpm para asegurarnos de que lo que hicimos fuera suficiente para que ambos lo usaran como un archivo de bloqueo importable o como opción alternativa. yarn.lock es, desafortunadamente, un subconjunto con pérdida, por lo que lo inverso no es cierto, pero agregaremos cosas para importarlo de todos modos. npm incluso obedecería las formas de árbol calculadas por Yarn (a diferencia de Yarn, que no lo haría).

De hecho, pkglock a partir de npm @ 6 se puede convertir de forma transparente en yarn.lock sin ejecutar un instalador, ya que describe un árbol completo con todos los metadatos relevantes.

No creo que pueda (pero tal vez me equivoque, siéntase libre de señalar cualquier error). El archivo de bloqueo de Yarn no admite por diseño múltiples rangos que se resuelven en una sola versión. Si tiene varios paquetes, cada uno dependiendo de lodash@^1.0.0 , todos usarán exactamente la misma versión. No es solo una optimización, sino también cómo codificamos las cosas en nuestro archivo de bloqueo.

Como el archivo de bloqueo npm es un árbol, esta propiedad no está garantizada y varios rangos idénticos pueden terminar usando diferentes versiones (lo cual está bien, ya que podría permitir optimizaciones ligeramente mejores al explotar las reglas de resolución de nodo). En tales circunstancias, la conversión package-lock.json -> yarn.lock tendría pérdidas, ya que no tendríamos otra opción que combinarlos en uno solo.

Por otro lado, un archivo de bloqueo de Yarn se puede transformar en un package-lock.json relativamente sin problemas, porque nuestras reglas son un subconjunto más estricto de las suyas (nuestros rangos fusionados se pueden transformar en un árbol sin pérdida, un árbol no se puede transformar en un rango combinado sin pérdida). Tenga en cuenta que solo estoy hablando del árbol de dependencias en sí, no estoy familiarizado con sus campos de metadatos.

Para ser honesto, no estoy del todo seguro de si decimos lo mismo o algo completamente diferente, solo quería aclarar un poco la situación 🙂

Idealmente, me gustaría que la advertencia incluyera algo acerca de que esta es una situación obsoleta (no estoy seguro de la redacción) y que las versiones futuras de hilo producirán un error. Tal vez se vincule a alguna documentación detallada sobre esto y cómo abordarlo.

@imsnif No estoy convencido de que se

Lo bueno es que @jmorrell podrá proporcionarnos métricas precisas para ver si la advertencia ha sido suficiente, y en base a eso elegiremos nuestro próximo movimiento.

¿Es la solución final deseada aquí un error útil cuando existe package-lock.json + importación de hilo?

Sí, junto con el modo de "actualización a error en CI" * ¡Creo que es un primer paso razonable!

(* Esto aún no existe, lo mencionaré en el # 5773 Yarn 2.0 WG)

@arcanis - Acerca de los @zkat (pero, por favor, @zkat , package-lock.json guarda el árbol físico y lógico, mientras que yarn.lock solo guarda el árbol lógico. Entonces, como se mencionó anteriormente, convertir package-lock.json => yarn.lock => package-lock.json perderá los datos del árbol físico. En mi opinión, en la mayoría de los casos, esto está bien, pero hay excepciones: por ejemplo. dependencias agrupadas.

Mi opinión personal es que ambos administradores de paquetes pueden beneficiarse de sincronizar su construcción de un árbol físico. Por lo que he visto, probablemente podamos extraer algunas reglas bien definidas sobre cómo se crea un árbol físico y ambos las siguen (idealmente con un módulo mantenido por todas las partes interesadas). Creo que esto resolverá el problema de compatibilidad, algunos problemas que yarn tiene con las dependencias empaquetadas, al tiempo que permite que cada administrador de paquetes mantenga sus peculiaridades únicas. (Aunque es cierto que soy bastante nuevo en esta discusión, por lo que puede haber cosas que desconozco, mis disculpas si estoy despertando a algunos perros dormidos).

Sin embargo, para el problema en cuestión: @arcanis : intentaré ofrecer solo un argumento más a favor de los errores generales en esta situación, y si no está de acuerdo, podemos quedarnos con las advertencias en lo que a mí respecta:
Si bien es bastante importante tener esto detectado en el nivel de CI, creo que un error allí sería significativamente más difícil de depurar (en promedio) que un error en el entorno local del desarrollador.
Si un desarrollador obtiene un error en su entorno local por usar la herramienta incorrecta, (probablemente) no irá ni un paso más allá. Simplemente dirían "oops" y usarían la otra herramienta. Ahorrará una enorme cantidad de tiempo, en lugar de detectarlo en el CI después de desarrollar una función y luego retroceder.
Una advertencia (como se mencionó anteriormente aquí) podría ser absorbida por algunas otras que los desarrolladores tienden a ignorar si el estado de salida es 0.
¿Qué piensas?

Además, en la situación que describí anteriormente, el archivo de bloqueo "externo" podría estar colocado comprensiblemente en .gitignore y, por lo tanto, el CI ni siquiera tendrá la oportunidad de saberlo. Como desarrollador distraído, podría pensar "Bueno, me da una advertencia oscura sobre mi entorno local, pero pasa CI, por lo que probablemente sea solo un problema local por mi parte, bueno".

Una advertencia (como se mencionó anteriormente aquí) podría ser absorbida por algunas otras que los desarrolladores tienden a ignorar si el estado de salida es 0.

Mi punto es que esta afirmación no está respaldada por ningún dato, a pesar de que tenemos una forma de recopilar algunos para luego tomar una decisión informada. En este contexto, la elección de la opción más radical que romperá el flujo de trabajo de los pueblos me parece un poco inútil y potencialmente perjudicial 😕

Además, creo que está pasando por alto la historia de usuario de "Estoy usando un administrador de paquetes y quiero probar otro", que creo que es bastante importante para todos los involucrados, tanto los mantenedores del administrador de paquetes como los usuarios. No sería genial si las personas no pudieran probar fácilmente npm 6 desde su proyecto Yarn (o, a la inversa, probar Yarn desde su proyecto npm).

Mi opinión personal es que ambos administradores de paquetes pueden beneficiarse de sincronizar su construcción de un árbol físico.

Este es un tema diferente, pero no estoy de acuerdo. Creo que existe una idea errónea de que Yarn es npm, lo cual es incorrecto. Si desea importar un proyecto a otro a través de un comando dedicado, estoy totalmente de acuerdo, pero convertir (o leer) silenciosamente archivos de bloqueo de un formato de terceros es una receta para el desastre:

• ignorará los archivos de configuración
• romperá el árbol físico la próxima vez que se agregue / elimine un paquete
• cualquier característica exclusiva de un administrador de paquetes no funcionará (espacios de trabajo, anulación de resolución, enlace :, ...)

Mi punto es que esta afirmación no está respaldada por ningún dato, a pesar de que tenemos una forma de recopilar algunos para luego tomar una decisión informada. En este contexto, elegir la opción más radical que romperá el flujo de trabajo de las personas me parece un poco inútil y potencialmente dañino, confuso.

Es cierto: no está respaldado por ningún dato. Definitivamente estoy especulando aquí (lo siento si no enfaticé esto). Si bien es posible que podamos tener una idea de la tendencia de la solución de advertencia, no podremos tener una idea de cuán conveniente es esto para los usuarios y si existe una solución más conveniente. Si confiamos en los datos, no creo que haya ningún resultado que no sea "no hubo absolutamente ningún cambio en la tasa de error de implementación de Heroku" que nos guíe hacia la solución de error general.

Estoy de acuerdo en que es muy importante no romper los flujos de trabajo de las personas. Es por eso que propuse el error como un cambio rotundo en 2.0.0 , con un texto en la advertencia que alertaría al usuario de que esta situación está obsoleta. También creo que podemos permitir el uso de un parámetro --force o config para anular este comportamiento. (Creo que esto también aborda su problema de probar el otro administrador de paquetes)

Este es un tema diferente, pero no estoy de acuerdo. Creo que existe una idea errónea de que Yarn es npm, lo cual es incorrecto. Si desea importar un proyecto a otro a través de un comando dedicado, estoy totalmente de acuerdo, pero convertir (o leer) en silencio archivos de bloqueo de un formato de terceros es una receta para el desastre

Creo que planteas preocupaciones importantes aquí que me encantaría abordar. Pero como dices, este es un tema diferente y no quiero descarrilar la conversación. ¿Quizás podamos discutirlo en otro número?

Creo que la conversación aquí se descarriló un poco, así que quiero ponerla en orden con algunas aclaraciones y un resumen:

1. Yarn y npm tienen diferentes estrategias de resolución y creación de árboles físicos y este es un factor clave para que existan ambos proyectos.
2. Los archivos yarn.lock y package-lock.json se crearon con objetivos específicos en mente y, por lo que puedo ver, estos objetivos no se alinean completamente pero tienen algunas superposiciones.
3. La diferencia en estos objetivos no hace que un formato sea superior a otro en general, solo intercambian cosas diferentes.

Sobre la base de estos, creo que mantener ambos formatos es fundamental para la innovación y satisfacer diferentes necesidades. Lo que se necesita es garantizar la portabilidad del proyecto con una pérdida mínima de datos entre los administradores de paquetes sin imponer una estrategia particular de administradores de paquetes al otro para permitir la experimentación libre.

Veo el reconocimiento y la advertencia contra otros archivos de bloqueo junto con la conversión adecuada con un mensaje claro sobre lo que se conserva y lo que se pierde como un gran valor para los usuarios de cada lado. Entonces, ahora la pregunta aquí en este número es cuál es el mejor flujo para los usuarios que tienen un archivo de bloqueo de paquete en su repositorio cuando ejecutan yarn .

Parece que la conversión automática es potencialmente peligrosa y una instalación incorrecta sin una salida puede dañar a ciertas personas. ¿Qué tal requerir que se establezca una configuración para que yarn sepa que tener un archivo de bloqueo de paquete está destinado al modo CI? Esta es una señal de los desarrolladores al hilo, diciendo: "Sé lo que estoy haciendo, así que por favor no trates de protegerme contra disculpas".

Pensamientos

¿Qué tal requerir que se establezca una configuración para que yarn sepa que tener un archivo de bloqueo de paquete está destinado al modo CI? Esta es una señal de los desarrolladores al hilo, diciendo: "Sé lo que estoy haciendo, así que por favor no trates de protegerme contra disculpas".

@BYK - suena genial. Con una adición: como @arcanis me convenció aquí y en discordia, podría ser bueno agregar también una advertencia en el modo no ci cuando la bandera de configuración no está configurada. Para que los desarrolladores tengan la oportunidad de saber que su compilación de CI podría fallar antes de presionar (y también para protegerse contra package-lock.json en .gitignore ).

@arcanis como lo mencionó

De las notas de la versión de NPM 5:

Una nueva función de archivo de bloqueo estandarizada destinada a la compatibilidad entre administradores de paquetes (package-lock.json)

Parece que el equipo de NPM anuncia package-lock.json como la solución universal; ¿Es (técnicamente) posible unir esa fuerza?

Una solución que me gustaría proponer sería "usar solo package-lock.json cuando ya exista". Así es básicamente como NPM "migró" de shrinkwrap a un archivo json de bloqueo.

Parece que el equipo de NPM anuncia package-lock.json como la solución universal; ¿Es (técnicamente) posible unir esa fuerza?

Ya lo discutimos, verifique el resto del hilo si no lo ha hecho. Esto no sucederá en el futuro a corto plazo.

Creo que estás pasando por alto la historia de usuario de "Estoy usando un administrador de paquetes y quiero probar otro", que creo que es bastante importante para todos los involucrados.

Probablemente esto no sea algo frecuente, el cambio de contexto. Elegí Yarn hace un tiempo y no he mirado atrás. Creo que es mejor poner un poco de peso detrás de la seriedad de por qué los archivos de bloqueo están ahí. Conviértalo en un error del que se puede excluir, en lugar de una advertencia que se ignorará. Cuando alguien confirma un archivo de bloqueo, es por una razón.

Nuestras estadísticas muestran que la mayoría de los usuarios de Yarn también usan npm. Los _proyectos_ mixtos son poco comunes, pero una sola persona que trabaja en varios proyectos, algunos de los cuales son npm y otros son Yarn, es bastante común. Para complicar aún más el problema, instalar scripts que ejecutan npm directamente es una cosa.

Quiero usar hilo, pero la mayoría de los proyectos en los que trabajo solo tienen archivos package-lock.json . No puedo agregar archivos yarn.lock . yarn import es lento y / o está roto. Actualmente mi
La opción _only_ es deshacerse del hilo y cambiar a npm.

Entiendo que el hilo es construido por desarrolladores de hilo solo para proyectos de hilo solo. Pero ¿qué pasa con el resto de nosotros?

Hola @Spongman - yarn import no debe romperse. Ahora debería poder importar package-lock.json por usted. Si tiene problemas, háganoslo saber.

Hice # 6103

Hola @Spongman : comenté en el problema, este caso específico se debió a un package-lock.json dañado. Estaría feliz de saber sobre cualquier otro problema.

npm puede usar ese archivo package-lock.json muy bien. el hilo debe ser más resistente.

Respondí a esto en el otro tema: pido que la discusión se mueva allí para mantener este tema en el tema. ¡Gracias!

Estaba observando y participando cuidadosamente en https://github.com/yarnpkg/yarn/issues/3614 (con actualmente 254: +1: s). Esa cuestión ya se ha cerrado y la discusión se ha trasladado aquí.

Ignorando los desafíos prácticos, en mi opinión, con mucho, la mejor UX sería proporcionada por una opción no mencionada en el resumen en la parte superior, pero mencionada por @thatlittlegit :

Creo que el objetivo final debería ser tener un formato de archivo de bloqueo compartido entre Yarn y npm.

Lo que también está respaldado por el punto de @BrainBacon :

Me parece extraño que cualquier tipo de proyecto deba especificar qué herramienta de gestión de paquetes se debe utilizar.

Nuevamente, ignorando los desafíos prácticos por un minuto, el contraargumento teórico fue hecho por @iarna en este hilo (y @jhabidas en el otro hilo ):

Hay un montón de ventajas de tener múltiples herramientas de uso activo que hacen diferentes compensaciones porque significa que los casos de uso de los usuarios se pueden cumplir mejor que con una única solución general.

Personalmente, no creo que este argumento deba aplicarse en este caso, como hice en un comentario en el otro hilo (con 95: +1: s, 2: -1: s):

Sí, estoy de acuerdo, Yarn quiere mantener su espacio independiente en la medida de lo posible, por lo que tiene la flexibilidad para brindar una mejor experiencia. Por eso, por ejemplo, la CLI de Yarn no es deliberadamente compatible con las NPM.

Sin embargo, creo que los archivos de bloqueo están fuera del espacio donde Yarn puede mantener razonablemente su independencia. package-lock.json y composer.lock están comprometidos con el repositorio , junto con package.json y composer.json . Estos no son archivos específicos de la herramienta, sino archivos específicos del proyecto que especifican las versiones de dependencia exactas con las que se garantiza que el proyecto funcionará.

...

Para que Yarn sea una herramienta útil, debe permitir a los desarrolladores seguir modelos estándar en sus proyectos, de modo que el proyecto pueda permanecer independiente de la herramienta. Lo cual, después de todo, es la razón por la que Yarn se creó sobre package.json y no sobre su propio archivo de dependencia separado.

Habiendo leído la mayor parte de este hilo, todavía estoy de acuerdo con mi evaluación inicial: si Yarn continúa consumiendo el mismo archivo de dependencia package.json del repositorio, idealmente debería emitir el mismo archivo package-lock.json en el repositorio , por lo que el repositorio puede permanecer independiente de las herramientas. Si Yarn lee sus dependencias de yarn.json lugar de package.json , no seguiría insistiendo en este punto.

Creo que deberíamos admitir que esta es la situación ideal , la experiencia de usuario perfecta. Sin embargo, entiendo el otro punto de @iarna :

Creo que un formato de archivo de bloqueo único no es un resultado probable, ya que existen diferentes compensaciones entre los formatos de archivo de bloqueo y la falta de consenso sobre cuál es el mejor.

(aunque no estoy de acuerdo con que "tener ambas herramientas capaces de entender mutuamente los archivos de bloqueo de la otra es suficiente").

Si el escenario ideal de permitir que los repositorios sean independientes de las herramientas definitivamente no se puede lograr (y veo los muchos comentarios sobre cómo los diferentes archivos de bloqueo se construyen de maneras fundamentalmente diferentes y contienen información diferente), entonces parece que hacia dónde parecemos ir. apetecible, que es:

• NPM / Yarn emitirá advertencias si detectan el archivo de bloqueo del otro (y tal vez una opción de configuración para convertir esto en un error)
• Ambas herramientas proporcionan mecanismos para convertir un archivo de bloqueo en otro

No creo que ninguno de los dos deba, bajo ninguna circunstancia, convertir y eliminar el archivo de bloqueo del otro. Esto significaría que los nuevos desarrolladores se convertirían para siempre de uno a otro y viceversa, dependiendo de la herramienta que utilice ese desarrollador (dado que demasiadas personas se comprometen con git commit -a ).

Tampoco estoy de acuerdo con el punto de @imsnif :

No creo que haya una buena razón para que un solo paquete tenga un archivo package-lock.json y yarn.lock.

Creo que es presuntuoso dictar lo que un desarrollador ejecuta en su computadora o en su entorno de producción. Es al menos cortés no ser más restrictivo de lo necesario. Si su proyecto solo lo ejecuta su equipo de desarrolladores, y todos tienen exactamente el mismo software en ejecución, excelente. Pero es posible que tenga un desarrollador al que le resulte mucho más fácil usar NPM que Yarn por alguna razón. Y especialmente si crea software de código abierto, desea que sea lo más fácil posible para los miembros de la comunidad comenzar a usarlo. Dado que NPM y Yarn son simplemente herramientas para instalar las mismas dependencias desde package.json , deberían funcionar. Un desarrollador debería poder ver package.json , tener una herramienta para interpretarlo y no tener que preocuparse más. Que solía ser el caso antes de que este conflicto de archivos de bloqueo llegara solo.

Hola @nottrobin , creo que entiendo de dónde vienes. Si ignoramos los desafíos prácticos y las diferencias filosóficas, definitivamente sería mejor para los usuarios de las diversas herramientas si todas consumieran el mismo archivo de bloqueo (esta es mi opinión personal, por supuesto).

Pero como no podemos ignorar dichos desafíos prácticos y en su mayoría parecemos haber acordado que las diferencias filosóficas tienen su lugar, creo que el compromiso al que llegamos (el que describiste anteriormente) es definitivamente "lo suficientemente bueno".

Tenga en cuenta que una suposición oculta en dicho compromiso es que la elección de la herramienta se realiza por proyecto en lugar de por la máquina del desarrollador o el entorno de producción.

Tenga en cuenta que una suposición oculta en dicho compromiso es que la elección de la herramienta se realiza por proyecto en lugar de por la máquina del desarrollador o el entorno de producción.

Sí, creo que esto es lo que más me preocupa, aunque creo que en el escenario que describí anteriormente todavía es posible tener un proyecto que soporte tanto Yarn como NPM.

Creo que, en última instancia, si los dos proyectos abandonan la misión de intentar permitir que un proyecto sea independiente de las herramientas, entonces realmente deberían dejar de compartir un archivo de dependencia. El hilo debería cambiar a la lectura yarn.json lugar de package.json . Cualquier otra cosa es desordenada y confusa.

Si los archivos de bloqueo npm ya tienen un superconjunto de relaciones de dependencia que los archivos de bloqueo de Yarn admiten, ¿por qué no admitir ambos en Yarn? Yarn podría cambiar a package.json y cualquier campo adicional que Yarn pudiera desear se podría agregar en el futuro (similar a cómo algunos editores SVG como Inkscape administran los metadatos del editor). Entonces Yarn podría tener el mismo formato de dependencia que npm y volver a ser compatible con yarn.lock, convirtiendo los archivos de bloqueo npm a cualquier estructura que Yarn quiera en la memoria con pérdida.

Creo que, en última instancia, si los dos proyectos abandonan la misión de intentar permitir que un proyecto sea independiente de las herramientas, entonces realmente deberían dejar de compartir un archivo de dependencia. El hilo debería cambiar a la lectura yarn.json lugar de package.json . Cualquier otra cosa es desordenada y confusa.

Quizás, quizás no. Ciertamente, esto requeriría un cambio de rotura masivo de la herramienta (hilo). Se han pasado por alto cambios menos radicales con beneficios más directos y medibles.

No digo que sea una mala idea, solo digo que no siento que sea práctica.

No digo que sea una mala idea, solo digo que no siento que sea práctica.

Estoy de acuerdo en que parece una gran pregunta. Pero lo que estoy diciendo es que esto parece un tema fundamental para el proyecto.

Hasta ahora, Yarn ha sido una herramienta que los desarrolladores pueden optar por usar en lugar de NPM para instalar dependencias de nodo para cualquier proyecto con un package.json . Ahora, como señala, requiere que los proyectos elijan explícitamente entre Yarn y NPM. Eso es un gran cambio y no debe hacerse accidentalmente. Este es el punto crucial para tomar esa decisión.

En mi opinión, hay 3 formas de avanzar:

1. Continúe siendo un reemplazo directo para NPM al encontrar una manera de alinear Yarn con NPM en todas las interfaces a nivel de proyecto (estandarice el archivo de bloqueo)
2. Diverge deliberadamente de NPM mediante el uso de interfaces a nivel de proyecto explícitamente diferentes (por ejemplo, yarn.json y yarn.lock )
3. Duplique el suministro de la mitad de la interfaz de NPM y la mitad de una interfaz diferente. En realidad, esto es lo mismo que el punto 2, pero a la mayoría de las personas les gusta el punto 1.

Creo que la tercera opción aquí confunde todo el espacio de Nodo y debilita ambas herramientas considerablemente.

Todavía puede ser compatible con versiones anteriores. Yarn podría tener un convertidor de archivos de bloqueo npm integrado, de modo que cuando vea package-lock.json, lo mantendrá allí y lo convertirá al formato yarn.lock en la memoria. Hasta donde yo sé, npm no puede hacer esto porque el archivo de bloqueo de Yarn tiene menos información que el de npm, por lo que, en mi opinión, sería mejor que Yarn se estandarizara con npm.

@nottrobin Creo que tienes razón en tu análisis, sin embargo:

Ahora, como señala, requiere que los proyectos elijan explícitamente entre Yarn y NPM. Ese es un gran cambio y no debe hacerse accidentalmente.

Creo que este siempre ha sido el caso, o al menos con el beneficio principal que inicialmente se promocionó que Yarn traería: la reproducibilidad de los árboles de dependencia. Puede registrar su yarn.lock , pero eso es prácticamente inútil si otros desarrolladores agregan / eliminan dependencias sin respetar ese archivo de bloqueo.

@nottrobin - Estoy de acuerdo con @Vinnl. Como mencioné anteriormente, aunque no quiero estar en posición de decirle a nadie cómo deberían funcionar, creo que usar tanto yarn como npm para instalar dependencias en el mismo proyecto es un antipatrón.

Aunque ambas herramientas técnicamente podrían poner mucho trabajo para que esto funcione, no creo que esto sea algo que nosotros, como mantenedores, debamos alentar. Hay innumerables otros beneficios de tener archivos de bloqueo intercambiables (como muestran las diversas discusiones en los diferentes hilos) pero no creo que este sea uno de ellos, personalmente.

pero eso es prácticamente inútil si otros desarrolladores agregan / eliminan dependencias sin respetar ese archivo de bloqueo.

Sí, supongo que hasta cierto punto Yarn estuvo en ese agua turbia desde el principio: la existencia de yarn.lock ya significaba que tenía parcialmente su propia interfaz. Creo que eso siempre fue un poco complicado, lo que sirvió al propósito de Yarn de querer que la gente pasara de NPM a Yarn, pero no de regreso.

Pero fue una decisión que me sentí más cómodo tomando para mi proyecto, porque al menos sabía que NPM todavía contaba con el apoyo total; dado que no proporcionaba bloqueo en primer lugar, continuaría funcionando tan bien como siempre.

Eso ha cambiado, porque NPM bloquea las dependencias. Si elijo vincular un proyecto a Yarn, ahora mantendré yarn.lock actualizado, y no package-lock.json , por lo que ya no es cierto que alguien pueda usar NPM de manera efectiva en mi proyecto.

¿Parece que estás diciendo que el hilo ya no está destinado a ser un reemplazo directo de npm? ¿Que se supone que solo debe usarse en proyectos de solo hilo?

Creo que si ese es el caso, entonces le debes a todos dejar este hecho en claro en la página de inicio del hilo: usa esto o npm, no ambos.

¿Parece que estás diciendo que el hilo ya no está destinado a ser un reemplazo directo de npm?

Nunca lo fue. La interfaz imitaba de alguna manera a npm para facilitar a los usuarios la comprensión de cómo usarlo, pero desde el principio algunas cosas funcionaron de manera diferente. La razón principal por la que algunas personas pensaron que era un reemplazo directo fue que npm simplemente carecía de las funciones para comparar.

Ahora que npm se está poniendo al día con algún aspecto y decide implementar las cosas de manera diferente, simplemente comienza a mostrar que tenemos diferentes enfoques y tomamos diferentes decisiones (por ejemplo, la reciente función de espejo sin conexión que npm implementó no es compatible con la actual). En resumen: nunca fue "seguro", simplemente funcionó accidentalmente.

Creo que si ese es el caso, entonces le debes a todos dejar este hecho en claro en la página de inicio del hilo: usa esto o npm, no ambos.

De hecho, tenemos instrucciones de migración . Su comentario me hizo notar que, lamentablemente, contiene un párrafo incorrecto que podría dar a la gente una impresión incorrecta 🙁 Aceptaríamos con mucho gusto un RP para cambiar este párrafo a algo más en línea con nuestras recomendaciones (es decir, usar Yarn de manera consistente en todos los equipos, para para asegurarse de que todos puedan beneficiarse de las diversas funciones que podría utilizar el proyecto).

Nunca fue

err ... entonces necesitas hablar con tu gente de marketing. https://yarnpkg.com/lang/en/docs/

Yarn interactúa directamente con muchas características de npm, incluido el formato de metadatos de su paquete, lo que permite una migración sencilla.

No tenemos personal de marketing, pero aceptamos buenas relaciones públicas 🙃

Sin embargo, en este caso particular, no suena tan mal. Hacemos interoperabilidad con muchas funciones, pero no con todas, y la migración es indolora en la mayoría de los casos (en el peor de los casos, está a yarn import distancia).

la migración es indolora

No estoy realmente interesado en la migración. Estoy buscando lo que se prometió aquí (estos tipos _definitivamente_ tienen gente de marketing): https://code.fb.com/web/yarn-a-new-package-manager-for-javascript/

Tiene el mismo conjunto de funciones que los flujos de trabajo existentes y, al mismo tiempo, funciona de forma más rápida, segura y fiable.

el hilo de hoy no es eso.

AFAICT hay 4 clases de usuarios aquí:

• los que _solo_ utilizan hilo en sus proyectos,
• aquellos que compraron el argumento de venta de facbook (arriba) pero aún no han encontrado ninguno de estos problemas de bloqueo,
• aquellos que están tratando dolorosamente de evitar las incompatibilidades convirtiendo manualmente los archivos de bloqueo cuando sea necesario, o usando otros trucos para que funcione,
• aquellos que simplemente abandonaron el hilo y cambiaron de nuevo a npm.

Realmente no quiero estar en la última categoría, pero parece que ahí es donde me empujan.

@Spongman, ¿qué te detiene de ese último? Probablemente podamos arreglarlo;)

@Spongman No estoy afiliado con Yarn, así que supongo que puedo ser un poco más directo: realmente no tiene sentido decir en este número que crees que la redacción es incorrecta. Si cree que la redacción es incorrecta, vaya a esa página en GitHub, haga clic en el botón Editar y envíe una solicitud de extracción con una mejor redacción. arcanis dejó en claro arriba que están abiertos a eso.

(Supongo que probablemente no puedas editar la publicación del blog, pero el sitio web es probablemente el más importante aquí).

Puedo ver en las respuestas de @arcanis que la posición oficial aquí parece ser que Yarn "nunca tuvo la intención" de continuar funcionando sin problemas junto con NPM.

Pero estoy totalmente de acuerdo con @Spongman en que esta es la impresión que dio Yarn, y realmente no creo que haya sido un accidente en ese momento. Ese fue su genio: podría haber mejorado la velocidad, la seguridad, etc., sin dejar de ser compatible con los estándares oficiales de NPM.

En cualquier caso, este problema hace que la posición de Yarn sea mucho más clara para mí de lo que era anteriormente y, por supuesto, los mantenedores de Yarn pueden optar por tomar la dirección que elijan.

Pero creo que está subestimando drásticamente la cantidad de personas que usaron Yarn precisamente porque creían que mantenía la compatibilidad con NPM (a nivel de proyecto) y nunca hubieran hecho el cambio de otra manera. Creo que el 254: +1: sy el 10: heart: s en https://github.com/yarnpkg/yarn/issues/3614 y los 57 votos positivos en " ¿Debo cometer yarn.lock y package-lock.json archivos? "aclare abundantemente esto.

Si Yarn abdica de cualquier responsabilidad en ese frente, creo que perderá no solo a @Spongman y mis equipos, sino a muchos otros más.

Francamente, realmente no entiendo el problema que tiene al usar solo Yarn, o solo npm. Lo que estás diciendo es básicamente "oye, no puedo obligar a mi equipo a usar Yarn, así que los obligaré a usar npm". Eso no tiene ningún sentido para mí. Si usa las funciones de Yarn, haga que todos usen Yarn, y si desea usar las funciones de npm, haga que todos usen npm. Es tan simple como esto.

Cualquier cosa intermedia significa que, como mínimo, tus construcciones no son consistentes en todo tu equipo, lo que va en contra de la premisa de Yarn, como se mencionó anteriormente. Uno de sus ingenieros podría comenzar a usar espacios de trabajo, y funcionaría, pero se interrumpiría en npm. Lo mismo del espejo sin conexión. Lo mismo para las resoluciones de dependencia. Peor aún, dado que algunos campos son completamente desconocidos por npm, silenciosamente haría lo incorrecto.

En cuanto a la comunicación, la publicación del blog de Facebook no menciona un reemplazo directo. Permítanme citar la parte donde se presenta Yarn. Literalmente dice que reemplaza el flujo de trabajo. Supongo que te confundió el "sigue siendo compatible con el registro npm", que es un punto justo que deberías llevar a npm, no a nosotros (está el npm cli, el registro npm y, por supuesto, npm Inc).

Yarn es un nuevo administrador de paquetes que reemplaza el flujo de trabajo existente para el cliente npm u otros administradores de paquetes mientras sigue siendo compatible con el registro npm.

¿Qué te detiene de ese último? Probablemente podamos arreglarlo;)

@zkat Eso es útil, gracias.

@nottrobin - No puedo hablar de las intenciones originales de yarn porque no estaba presente en ese momento. Sin embargo, estaba trabajando en un entorno mixto de hilo / npm con varias docenas de repositorios.

Puedo decir que estaba perfectamente claro para todos los desarrolladores involucrados en ese entonces que la elección de yarn / npm era una elección por repositorio, al igual que la elección de express / hapi, mobx / redux, etc. Esto se hizo aún más claro como npm @ 5 salió con su propio formato de archivo de bloqueo y algunos desarrolladores decidieron comenzar a usarlo con nuevos repositorios.

Cuando un desarrollador instalaba una dependencia con la herramienta incorrecta, creaba un lío incluso antes de npm @ 5 , porque esa dependencia no se bloquearía de forma consistente. Causó problemas en nuestros diversos entornos y estaba muy claro para todos los involucrados que se trataba de un error *.

Me doy cuenta de que esto puede ser confuso, y entiendo que esto puede no ser 100% claro para todos sin que sea culpa suya, pero no creo que sea correcto cambiar drásticamente la herramienta para que se ajuste a ese malentendido. A mi modo de ver, el hilo es una caída en el reemplazo de npm por repositorio en lugar de por caja.

* Por supuesto, esa situación particular de múltiples repositorios sin espacio de trabajo con herramientas mixtas de hilo / npm no era ideal a nivel humano en lugar de a nivel técnico para exactamente esos posibles errores y finalmente se solucionó. Utilizo este ejemplo aquí para mostrar que las dos herramientas pueden funcionar una al lado de la otra si se abordan correctamente.

Francamente, realmente no entiendo el problema que tiene al usar solo Yarn, o solo npm.

Sí, tú @arcanis y @imsnif han dejado claro que no entiendes. El único punto que estoy diciendo es que mucha gente (mira el: +1: s) hizo la misma "mala interpretación" y quiere que Yarn trabaje junto con NPM, sin importar si lo entiendes o no. Si Yarn no es la herramienta para nosotros, que así sea.

(Solo un punto final: @imsnif es completamente ridículo comparar una herramienta para instalar dependencias de Node con una elección de proyecto como express vs hapi, mobx vs redux. Esas son características fundamentales de su aplicación. Si no puede ver la diferencia obvia, no es de extrañar que no entiendas mi punto).

De todos modos, ya terminé. Creo que he dejado claro mi punto lo mejor que he podido.

Para proyectos de código abierto, nunca se trata de obligar al "equipo" a utilizar hilo o npm. Es cuestión de qué es lo más conveniente para todos. En el mundo real, npm es el rey, así que, a menos que el hilo pueda jugar bien en un mundo npm, entonces está muerto.

^ Esto

Me temo que eso también es un error. Durante el año pasado, Yarn pasó del 20% del total de solicitudes al registro npm al 40% en abril . La última vez que escuché las estadísticas (directamente de la gente de npm, ya que nuestras estadísticas se rompieron recientemente cuando el registro de npm pasó a Cloudflare), fue aproximadamente el 48% de las solicitudes. En el mundo real real, Yarn y npm coexisten, simple y llanamente.

Ahora agradecería si pudiéramos volver al tema en cuestión, que es: ¿ quién está dispuesto a escribir un PR para escribir una advertencia cuando detectamos un archivo package-lock.json en el momento de la instalación? Gracias.

Psst, @arcanis - https://github.com/yarnpkg/yarn/pull/5920

Impresionante: heart_eyes:

Entre esto y su trabajo en yarn import , ¿podemos cerrar este problema entonces?

Pensé que esperaríamos a que @jmorrell nos diera algunas estadísticas de cómo esto afecta el problema en Heroku para que podamos decidir si esto es suficiente o si nos gustaría cambiar algo (advertencia / error, etc.) ¿wdyt?

EDITAR: afaik la advertencia aún no se ha publicado, por lo que todavía tenemos algo de tiempo para esperar.

Me temo que eso también es un error.

¿Cómo es eso? El volumen de tráfico en npm no le dice nada sobre si el proyecto es de código abierto o no.

una evaluación más precisa sería contar qué proyectos de github tienen 0,1 o 2 de (yarn.lock, package-lock.json). personalmente, _nunca_ he visto un proyecto de código abierto (de cualquier tamaño apreciable) en github que tenga un archivo yarn.lock y _no_ package-lock.json (excepto lo obvio).

En mi opinión, si va a mantener archivos de bloqueo separados, AMBOS administradores de paquetes deberían detectar el archivo de bloqueo y el ERROR del otro (posiblemente con un indicador de anulación).

Todos: les pediría que nos mantengamos en el tema y que desconectemos los comentarios que no estén directamente relacionados (por ejemplo, nuestro canal de Discord). Hay muchas personas suscritas a este hilo y, para ser justos, creo que la discusión del hilo npm <> no pertenece aquí. ¡Gracias!

No he leído toda la banda de rodadura, pero al usuario de IHMO se le debe notificar al menos que hay una ambigüedad:

si npm ve un archivo yarn.lock, entonces npm debería imprimir algo como:
"ADVERTENCIA: este proyecto parece usar hilo, tal vez debería usar 'hilo' en lugar de 'npm install'"

si yarn ve el archivo package-lock.json, entonces yarn debería imprimir algo como:
"ADVERTENCIA: este proyecto parece usar npm, tal vez debería usar 'npm install' en lugar de 'yarn'"

Y como se sugirió anteriormente, una forma de "preferir" el administrador de paquetes (en package.json).

Puedo decir que estaba perfectamente claro para todos los desarrolladores involucrados en ese entonces que la elección de yarn / npm era una elección por repositorio, al igual que la elección de express / hapi, mobx / redux, etc.

Esto no me quedó claro en absoluto. Hasta ahora pensaba que era una elección local del desarrollador, y varios desarrolladores podían coexistir en un solo repositorio usando el que quisieran, mientras que era _ un poco más conveniente_ usar solo uno de manera consistente. Sin embargo, los ejemplos de express / hapi, etc. son buenos y dejan en claro que no es una opción. Esto debería tener más visibilidad.

Agregue un campo en package.json para indicar qué administrador de paquetes debe usar un proyecto

"package-manager": "yarn"

Creo que esta es la mejor solución, si se implementa en todos los administradores de paquetes.

Entonces, los administradores de paquetes DEBEN negarse al 100% a continuar si se les llama en el proyecto incorrecto, tal como se esperaría un error si necesitara redux pero luego intentó llamar a funciones mobx en él. Deben emitir un error, no una advertencia, e informar al usuario cómo proceder con el administrador de paquetes correcto.

Agregue un campo en package.json para indicar qué administrador de paquetes debe usar un proyecto
"package-manager": "yarn"

Creo que esta es la mejor solución, si se implementa en todos los administradores de paquetes.

Si quieres que npm considere esto, te animo a que inicies una discusión en el lugar apropiado , pero diré que no me gusta esta dirección. Me gustaría ver una convergencia entre los administradores de paquetes, no una divergencia.

Recomendaría contra algún nuevo campo "administrador de paquetes", en su lugar recomendaría la estrofa engines que ya tiene técnica anterior.

Tanto los documentos de yarn como de npm mencionan (de pasada) el uso de engines.npm y engines.yarn para especificar las versiones de cada uno que se espera que se utilicen. El hilo incluso producirá un error si la versión del hilo no satisface engines.yarn .

https://yarnpkg.com/en/docs/package-json#engines -
https://docs.npmjs.com/files/package.json#engines

Incluso si ni npm ni yarn marcan engines para el administrador "competidor" (lo cual sería bueno), usar este campo sigue siendo una excelente manera de comunicar a otros desarrolladores qué administrador se espera que se use. (si la existencia de package-lock.json o yarn.lock no es una pista suficiente)

Me gustaría ver una convergencia entre los administradores de paquetes, no una divergencia.

Convenido. O convergencia o rechazo.

pero el actual término medio, ambiguo y erróneo, es perjudicial.

Sigo pensando que simplemente lanzar un error en presencia del archivo de bloqueo de los demás requeriría la menor fricción para los proyectos existentes.

Si desea que npm considere esto, le animo a que inicie una discusión en el lugar apropiado.

Gracias, me acabo de registrar. Hay un hilo reciente en esta dirección: https://npm.community/t/npm-install-should-warn-about-the-presence-of-yarn-lock-files/1822

Mi voto es a favor de un error completo en lugar de solo una advertencia, por lo que no estoy seguro de si debería agregar a ese hilo o comenzar uno nuevo.

Me gustaría ver una convergencia entre los administradores de paquetes, no una divergencia.

Igual que aquí. Aunque son incompatibles en este momento, la divergencia ya ocurrió y ya está causando fricciones a muchos usuarios y proyectos.

Cualquier convergencia que surja de las conversaciones posteriores entre los equipos llevará tiempo. Cuando llega, los errores propuestos pueden eliminarse y los usuarios pueden comenzar a cambiar y mezclar administradores de paquetes sin un juego de niños.

Agregar los errores ahora evita más confusión y no detiene los esfuerzos en la dirección de la convergencia.

Recomendaría contra algún nuevo campo "administrador de paquetes", en su lugar recomendaría la sección de motores existentes que ya tiene técnica anterior.

Eso suena razonable. No estoy apegado a ningún método en particular para detectar la presencia de un administrador de paquetes incompatible.

Para agregar ilustración, mi caso de uso en particular es gatsbyjs. La situación es exactamente la misma informada por @gaearon aquí :

Para crear usuarios de la aplicación React, esto es extremadamente confuso porque su proyecto se crea con Yarn (si Yarn existe en el sistema) pero luego siguen los documentos de alguna biblioteca que les dice que npm install, y eso hace volar todo el árbol.

Para evitar este problema, aunque gatsby usa hilo, también agrega package-lock.json a los arrancadores predeterminados . Pero luego los usuarios terminan con archivos bloqueados y comienzan a ver advertencias. Es fácil eliminar uno de ellos, pero complica la experiencia de incorporación.

Gracias a todos por sus comentarios.

@jmorrell - https://github.com/yarnpkg/yarn/pull/5920 fue lanzado en 1.9.2 el 25 de julio. Hace poco más de un mes, sé que no es mucho tiempo (y seguramente no todos se han actualizado), pero ¿tal vez tenga algunas ideas para compartir sobre los errores de doble archivo de bloqueo en Heroku desde entonces?

@imsnif ¡ Gracias por el recordatorio por correo electrónico! Perdón por perderme la actualización aquí.

Aquí hay un gráfico del número de aplicaciones que experimentaron esta falla particular cada semana en 2018.

(He redactado la escala y, pero esto representa cientos de desarrolladores y muestra la tendencia)

1. La caída en julio proviene de un problema no relacionado con S3

2. Al observar la tendencia después del 25 de julio, la advertencia parece haber tenido un efecto sustancial en la cantidad de personas que experimentaron este error. Estoy algo sorprendido por la magnitud del cambio.

@jmorrell - ¡esto es realmente genial!
Admito que también estoy bastante sorprendido por esto.

Creo (en el lado del hilo) que este problema puede considerarse resuelto. ¿Estás de acuerdo?

Sigo pensando que el consejo de eliminar package-lock.json para corregir el error es engañoso; en general, esto dará como resultado el uso de un conjunto diferente de versiones de paquetes y (de nuevo, en general) provocará incompatibilidades y roturas. Además, este consejo solo es útil para aquellos que toman decisiones sobre qué administrador de paquetes está utilizando un proyecto. los colaboradores generales que sigan este consejo también encontrarán problemas.

En mi opinión, si existe un package-lock.json y yarn no puede garantizar que las versiones que instala sean las mismas que las que instalaría npm , entonces debería fallar con un error .

Gracias de nuevo por tu aportación @Spongman. Siento que todo esto ha sido bien discutido en el (muy largo) hilo de arriba y no creo que tenga sentido reiniciarlo nuevamente. Creo que todos entendemos su posición. Gracias por participar.

A menos que @jmorrell me diga lo contrario en la próxima semana, lo consideraré hecho y cerraré este problema.

@imsnif Tomando un camino diferente y observando las fallas de septiembre hasta ahora (1 de septiembre - 20 de septiembre), esta sigue siendo la razón número 1 por la que Node se basa en Heroku. Ocurre el doble que el siguiente caso de falla conocido más común: package.json es JSON no válido. Una vez más, redactando números exactos, así es como se compara con otros problemas.

No he visto ningún movimiento de npm en esto, así que crearé un PR agregando una advertencia allí también y veré que se acepte.

Creo (en el lado del hilo) que este problema puede considerarse resuelto. ¿Estás de acuerdo?

No creo que esto se haya resuelto para los usuarios y la experiencia del usuario aún no es excelente. Pero puedo ver cómo cambian los números una vez que npm también brinda comentarios a un usuario que golpea este caso.

Dejaré que tú decidas si quieres cerrar esto o hacer más cambios. Me complace abrir una nueva edición en unos meses si sigue siendo un gran problema para los usuarios.

@jmorrell - dado que este tema está atrayendo mucha atención y la conversación se reinicia e incluso se repite, creo que sería mejor cerrarla ahora con la información que tenemos.

Si, con npm proporcionando también una advertencia, todavía vemos un problema, definitivamente estaría dispuesto a comenzar la discusión del error nuevamente (o buscar otras soluciones). Por favor, envíeme un ping personalmente en ese caso.

¡Gracias por mencionar esto, contribuir y hacer que todos estos cambios sucedan! Personalmente, creo que el hilo es mejor después de este número.