No creo que esto sea un error. Pude reproducir el problema, pero la diferencia fue

52,55d51
< ansi-regex@*:
<   version "3.0.0"
<   resolved "https://registry.yarnpkg.com/ansi-regex/-/ansi-regex-3.0.0.tgz#ed0317c322064f79466c02966bddb605ab37d998"
<
1352c1348
< imurmurhash@*, imurmurhash@^0.1.4:
---
> imurmurhash@^0.1.4:

Este cambio es solo una optimización del archivo de bloqueo y no cambia la semántica. Estamos planeando agregar una advertencia cuando el archivo de bloqueo necesite una actualización al ejecutar yarn install pero si desea asegurarse de que su archivo de bloqueo permanezca igual y sea preciso, debe usar la opción --frozen-lockfile .

Debo admitir que esto es un poco intuitivo y estamos tratando de encontrar una buena solución para esto. Puede seguir o contribuir a la discusión sobre # 4147.

Si está de acuerdo en que esto no es un error y el # 4147 es un buen lugar para continuar la discusión, por favor cierre el problema :)

@BYK gracias por su

4147 parece ser exclusivamente sobre el caso en el que yarn.lock y package.json no están sincronizados; de hecho, la única vez que se menciona la optimización es en este comentario: https://github.com/yarnpkg/yarn/issues/4147 #issuecomment -321894341 - y ese comentario toca el tema que me preocupa: hilo modificando el archivo yarn.lock cuando no se han realizado cambios en package.json .

Me parece que el archivo yarn.lock solo debería cambiar si mis dependencias están cambiando de alguna manera. De hecho, hasta este punto, les he estado diciendo a mis desarrolladores que si ven un cambio en el archivo yarn.lock , es hora de ejecutar yarn install . Con las actualizaciones recientes, varios informaron que después de recibir mis cambios y ejecutar yarn install , su archivo de bloqueo cambió (la optimización). Esto crea una situación confusa: ¿deberían realizar el cambio? ¿Debo optimizar de alguna manera el archivo de bloqueo (es posible)?

Parece que tendré que, a corto plazo, agregar --frozen-lockfile true a .yarnrc en todos mis repositorios, pero no soy un gran admirador de esta solución porque excluye el flujo de trabajo mencionado en # 4147 donde edita package.json y luego ejecuta yarn install .

¿Es la intención que cualquier invocación de hilo pueda modificar yarn.lock ?

@BYK Lamento molestarlo por esto porque sé que está muy ocupado, pero espero obtener una respuesta definitiva al respecto. Mi flujo de trabajo para distribuir cambios de dependencia a mi equipo se ha convertido en esto:

yarn add [blah]
rm -r node_modules yarn.lock
yarn install
rm -r node_modules
yarn install

Esto parece actualizar el archivo de bloqueo correctamente (ver # 4476) y luego optimizar el archivo de bloqueo para que mis compañeros de equipo no revisen los cambios del archivo de bloqueo.

¿Mi equipo está usando hilo incorrectamente? ¿Deberíamos esperar que el archivo de bloqueo cambie con cada comando install ?

@artlogic En mi yarn install optimizar el archivo de bloqueo es contrario a la intuición, pero aún así es algo que cada desarrollador de su equipo podría comprometer con seguridad. No entiendo por qué quiere prohibir eso.

Dicho esto, su flujo de trabajo puede provocar efectos secundarios inesperados, ya que prácticamente está renunciando a las versiones bloqueadas. Eliminar el archivo de bloqueo significa que yarn tiene que resolver todas las versiones de dependencias nuevamente, e intentará buscar la versión más actual como se indica en su package.json lo que provocará una posible rotura, especialmente. si más de una dependencia se rompe al mismo tiempo en una versión futura.

Si aún desea hacer cumplir que la instalación no toque el archivo de bloqueo, entonces debe usar la bandera frozen-lockfile :

 yarn add {blah}

Verifique el archivo de bloqueo, y luego otro desarrollador usaría:

   yarn install --frozen-lockfile

NO AGREGUE --frozen-lockfile a true en .yarnrc ya que le impide actualizar, consulte: # 4570

Si desea actualizar sus dependencias, ejecute:

 yarn upgrade

Si desea actualizar solo una dependencia:

  yarn upgrade {blah}

También puede instalar una versión específica de una dependencia:

  yarn install {blah}@1.5

Esto permite un mayor ajuste y menos dolores de cabeza a largo plazo.

@ k0pernikus : gracias por su respuesta detallada. Primero, debería disculparme por combinar dos problemas: el número 4476 está impulsando parte de mi flujo de trabajo. El hecho de que yarn upgrade parezca estar algo roto no tiene nada que ver con este problema, por supuesto.

En cuanto al flujo de trabajo, no puedo imaginar que el mío sea el único equipo donde un desarrollador está a cargo de mantener / probar nuevas dependencias mientras los otros desarrolladores trabajan en la base del código. El gran problema que tengo con lo que ha comenzado sucedió es que instalaría / probaría nuevas dependencias, les diría a todos que ejecuten yarn install y luego obtengo 4-5 preguntas sobre si el yarn.lock modificado debe confirmarse . Parece que estaría en un peor lugar si dijera "si el archivo de bloqueo cambia, confírmelo" porque en ese momento podría terminar con un bloqueo de confirmación que se parece a esto:

• yarn.lock cambiado (dev4)
• yarn.lock cambiado (dev3)
• yarn.lock cambiado (dev2)
• yarn.lock cambiado (dev1)
• Dependencias actualizadas (yo)

Sin embargo, podría ser que esta sea la forma en que se pretende que funcione el hilo, por lo que para los proyectos de mi equipo cambiaremos todos nuestros repositorios para usar un archivo de bloqueo congelado de modo que solo add y upgrade causen lockfile para cambiar.

Un escenario adicional ... parece que esto podría ser una molestia potencial para proyectos con muchos contribuyentes porque potencialmente cada vez que clonan e instalan, el archivo de bloqueo podría cambiar. Ciertamente no querría estas optimizaciones en solicitudes de extracción. ¿Es la intención que la mayoría de los proyectos de software libre que utilizan hilo pasen también a un archivo de bloqueo congelado?

@artlogic Nuestro equipo tiene --install.pure-lockfile true en el .yarnrc del proyecto exactamente por esta razón.

@jboler : no había visto esa configuración antes. Tendré que echarle un vistazo, pero parece que voy a sugerir que agreguemos eso a .yarnrc para todos nuestros repositorios, y todos los repositorios de cualquier proyecto FOSS que tenga.

Si alguien del equipo de hilo puede confirmar que la intención es que yarn install pueda y cambie el archivo de bloqueo en cada ejecución (a pesar de que no haya cambios en las dependencias), cerraré este problema.

@artlogic perdón por la respuesta tardía.

La cuestión es que se __espera__ que yarn install cambie potencialmente el archivo de bloqueo. Sé que esto no es ideal y necesita una mejor comunicación. Realmente quiero tener un mejor valor predeterminado, pero mientras tanto, creo que algo como @jboler sugirió, pero tal vez usar --frozen-lockfile lugar, sería la mejor solución hasta que averigüemos cómo debería comportarse el hilo en diferentes escenarios como para flujos de trabajo donde las personas prefieren simplemente editar package.json para actualizar las dependencias en lugar de usar yarn add etc.

@BYK Estuve de acuerdo con @artlogic . Este comportamiento es muy confuso:

El gran problema que tengo con lo que ha comenzado es que instalaría / probaría nuevas dependencias, les diría a todos que ejecuten la instalación de yarn y luego recibiré 4-5 preguntas sobre si el yarn.lock cambiado debería confirmarse.

Nuestro equipo consta de ~ 50 personas que ejecutan yarn install todos los días :(

@vkrol debería poder registrar un archivo .yarnrc que tenga --install.frozen-lockfile true o --install.pure-lockfile true para evitar problemas hasta que Yarn cambie su comportamiento. ¿Eso ayudaría?

@BYK pure-lockfile nos ayudará, pero no frozen-lockfile . Si entiendo correctamente, yarn install fallará con un error si el archivo de bloqueo congelado está habilitado. Este comportamiento es absolutamente inaceptable en nuestro caso.

@vkrol mi preferencia es frozen-lockfile ya que fallará solo si su archivo de bloqueo necesita ser cambiado y no es consistente. Con pure-lockfile puede tener un archivo de bloqueo cerca de ser inútil o muy inexacto, pero aún así no obtendrá una falla. Yarn simplemente usaría las resoluciones internas que calculó felizmente. Si todos los miembros de su equipo usan exactamente la misma versión de Yarn, esto debería estar bien. De lo contrario, puede ser peligroso.

@BYK tal vez no entiendo correctamente el comportamiento de frozen-lockfile . ¿Falla cuando el archivo de bloqueo es coherente con el contenido de package.json, pero se necesita alguna optimización interna?

@vkrol no debería fallar cuando el archivo se pueda optimizar aún más, pero es consistente con package.json y es consistente en sí mismo. Si no es así, es un error. Incluso hay una prueba para esto: https://github.com/yarnpkg/yarn/blob/0415b07b3293ab125a77f3f66fe14034d6e5b376/__tests__/commands/install/lockfiles.js#L72 -L84

@BYK No lo sabía. Probaré esta opción, ¡gracias! Creo que este hecho debería documentarse en alguna parte.

@BYK

no debería fallar cuando el archivo se pueda optimizar aún más, pero es consistente con package.json y es consistente en sí mismo.

Encontré algunas desventajas del uso de esta bandera. Si yarn.lock se puede optimizar, las invocaciones repetidas de este comando yarn install --frozen-lockfile no se optimizan mediante la verificación de "integridad" como sin este indicador. ¿Es esto un error? ¿Necesito crear el problema por separado?

@BYK Gracias por tu respuesta. Para los proyectos de mi equipo, ahora estamos usando frozen-lockfile y las cosas están funcionando (relativamente) bien. Sin embargo, este tema sigue siendo bastante preocupante para mí. Específicamente, las optimizaciones innecesarias que realiza el hilo en el archivo de bloqueo al ejecutar yarn install .

Este es el ejemplo más claro que puedo dar de dónde este comportamiento causa problemas:

1. Agrego una nueva dependencia usando yarn add [blah] y confirmo mi package.json y yarn.lock actualizados.
2. Los colaboradores de mi paquete muestran los cambios y notan que yarn.lock se ha actualizado y, por lo tanto, ejecutan un yarn install .
3. En algunos casos, estos contribuyentes terminan con un yarn.lock modificado después de la instalación. ¿Qué deberían hacer en este caso? ¿Es una carrera para ver quién puede enviar la solicitud de extracción primero?

Para ser claros, no tengo ningún problema con yarn install modificar yarn.lock si package.json ha sido modificado. Mi problema es la optimización cuando package.json no se ha cambiado. Veo tres posibles soluciones:

1. Dirija cualquier proyecto que administre dependencias de manera centralizada para agregar --install.frozen-lockfile true a un archivo .yarnrc . Esto probablemente sería MUCHOS proyectos, supongo que la mayoría de los paquetes de NPM.
2. Proporcione un interruptor para forzar hilo a optimizar el archivo de bloqueo durante la fase de adición, por ejemplo, yarn add --optimize [blah] . Luego, dirija a los mantenedores de paquetes que siempre usen ese interruptor.
3. No permita que el hilo optimice yarn.lock durante la fase de instalación a menos que el package.json parezca haber sido actualizado.

Abogo por la opción 3, pero podría ver que la opción 2 también es una opción razonable.

¡Gracias por tu tiempo!

Me gusta la idea de que yarn install no actualice el archivo yarn.lock sino que emita una advertencia que diga que "Su archivo yarn.lock no está actualizado, ejecute yarn blah para actualícelo ahora`.

@BYK ¿ ~ no ~ aplica el hilo optimizaciones a yarn.lock en yarn install lugar de cuando se ejecutan add / upgrade ?

editar: corregir error tipográfico

@ spencer-brown: según lo que he visto, en realidad aplica optimizaciones en la instalación; eso es lo que encuentro problemático

¿No debería ejecutarse la optimización de yarn.lock en yarn add? yarn.lock cambiará de todos modos. Esta es la opción número dos en el comentario reciente de @artlogic , ¿verdad? ¿Por qué no se produce la optimización entonces, para que nadie más tenga que realizar otro cambio de hilo.

@artlogic oops, error tipográfico :) - mi comentario debería decir "hace"; editado.

Usamos mucho el compositor y composer install nunca toca el archivo de bloqueo.

composer update o composer require (equivalente a yarn add ) deben ejecutarse para que se realicen cambios u optimizaciones en el archivo de bloqueo.

En muchos años, nunca hemos tenido que preocuparnos por el comportamiento ambiguo de composer install .

Me doy cuenta de que el hilo cumple una función ligeramente diferente, pero el compositor tiene el problema equivalente de realizar actualizaciones manuales en composer.json y no está sincronizado con el archivo de bloqueo. Actualmente, composer install ignorará completamente el archivo composer.json y emitirá una advertencia.

Usamos mucho el compositor y composer install nunca toca el archivo de bloqueo.

composer update o composer require (equivalente a yarn add ) deben ejecutarse para que se realicen cambios u optimizaciones en el archivo de bloqueo.

En muchos años, nunca hemos tenido que preocuparnos por el comportamiento ambiguo de composer install .

Me doy cuenta de que el hilo cumple una función ligeramente diferente, pero el compositor tiene el problema equivalente de realizar actualizaciones manuales en composer.json y no está sincronizado con el archivo de bloqueo. Actualmente, composer install ignorará completamente el archivo composer.json y emitirá una advertencia.

Hola niños, el archivo de bloqueo nunca debería cambiar en instalaciones posteriores. es simplemente tonto. si cree que vale la pena tocar la optimización, simplemente cree un archivo separado que no entre en el control de versiones.

Al igual que con Gemfile.lock de Bundler, el objetivo de yarn.lock es que cada vez que se ejecuta la instalación de hilo, puede garantizar resultados deterministas en todos los entornos. Si la instalación de hilo cambia el archivo de bloqueo, perderá esa garantía. Otros comandos como yarn add o yarn update obviamente deberían cambiar yarn.lock pero no así la instalación de yarn. Nuestro equipo se ha encontrado con problemas en los que tenemos versiones de paquetes ligeramente diferentes instaladas en diferentes entornos, que es exactamente lo que no queremos.

Me inclino a pensar que yarn install --pure-lockfile debería ser el valor predeterminado, y podría haber una opción --fix-my-dev-process-inconsistencies-for-me-magically para obtener el comportamiento actual.

@ryancastle --pure-lockfile no le dirá que hay una actualización para su archivo de bloqueo. Solo no genera uno. Esto aún puede provocar un comportamiento inesperado. --frozen-lockfile fallará si se requiere una actualización.

He estado operando con --install.frozen-lockfile true en mi .yarnrc por un tiempo y parece funcionar de una manera sensata. El truco consiste en crear el yarn.lock inicial para el repositorio sin esa marca en efecto. Una vez creado, las instalaciones no pueden cambiar el yarn.lock , pero las actualizaciones sí. Una vez que comencé a usar este flujo de trabajo, el número de cambios accidentales en yarn.lock redujo a cero.

@artlogic Sidenote: solía tener frozen-lockfile true en mi .yarnrc también, ahora solo lo hago cumplir en el servidor de compilación, ya que encontramos problemas que eran cambios intencionales en el yarn.lock no se hicieron, por ejemplo, al intentar sincronizar un package.json cambiado con el yarn.lock , porque un desarrollador editó manualmente el package.json o usó npm para agregar dependencias.

Ver: https://github.com/yarnpkg/yarn/issues/4570

El caso de uso de @ k0pernikus es la razón por la que no hemos hecho --frozen-lockfile el valor predeterminado con yarn install . Honestamente, no sé cuál sería un buen compromiso sin obstaculizar a las personas que editan package.json y luego ejecutan yarn install para actualizar el archivo de bloqueo. Propuse una bandera o un nuevo comando como yarn sync pero la idea debe ser desarrollada y luego juzgada por la comunidad antes de ser implementada.

Además, este sería un cambio importante, por lo que requeriría Yarn 2.x :)

una bandera o un nuevo comando como sincronización de hilo

me suena bien 👍. y yarn install podría mostrar un aviso "package.json y yarn.lock no están sincronizados. Ejecute 'yarn sync' para actualizar el archivo de bloqueo"

Honestamente, no sé cuál sería un buen compromiso sin obstaculizar a las personas que editan package.json y luego ejecutan yarn install para actualizar el archivo de bloqueo.

Creo que en cierto punto se debe tomar una decisión sobre cuál es el flujo de trabajo adecuado. Para mí, habilitar esto casi parece alentar un anti-patrón.

Propuse una bandera o un nuevo comando como sincronización de hilo, pero la idea debe desarrollarse y luego ser juzgada por la comunidad antes de implementarla.

Para mí, esto parece un compromiso razonable. Si insiste en editar manualmente su package.json , entonces tiene sentido ejecutar un comando para volver a sincronizar las cosas.

Esto es lo que me gustaría ver:

• yarn install sin yarn.lock crea el yarn.lock .
• yarn install con yarn.lock no lo modifica. Si encuentra que hay una discrepancia entre yarn.lock y package.json se devuelve un error (como @indeyets indicado).
• yarn sync (o tal vez yarn install -s ) vuelve a sincronizar yarn.lock con package.json .

Todavía tengo una preocupación subyacente de que yarn install modifique yarn.lock incluso cuando package.json no esté sincronizado con el archivo de bloqueo. Verá arriba que realiza algunas "optimizaciones". ¿Sería posible al menos deshabilitar este comportamiento sin un cambio importante?

Todavía tengo una preocupación subyacente de que la instalación de yarn modifica yarn.lock incluso cuando package.json no está sincronizado con el archivo de bloqueo. Verá arriba que realiza algunas "optimizaciones". ¿Sería posible al menos deshabilitar este comportamiento sin un cambio importante?

El mismo sentimiento aquí. Pensé que esta era la razón específica por la que este problema seguía abierto. Como la "sincronización" se analiza en el n. ° 4147

Es por eso que busqué este problema en primer lugar.

¿Fusionamos esto y el # 4147?

@BYK Creo que casi todo lo que se ha discutido aquí se puede fusionar con # 4147. Como dije antes, creo que lo único que todavía me preocupa son las "optimizaciones" que realiza yarn install en yarn.lock incluso cuando no se han realizado cambios en package.json .

Mi pensamiento es que, como una solución provisional en el camino hacia Yarn 2.0, estas optimizaciones deberían desactivarse. No creo que esto sea un cambio radical.

Estoy 100% de acuerdo con @artlogic .

Estaba configurando CircleCI y mi compilación seguía fallando y lo rastreé hasta un problema de almacenamiento en caché con yarn.lock . Viniendo de Rails, esperaría que el archivo de bloqueo esté bloqueado en un comando de instalación.

Esto es lo que se sugiere para la verificación de caché en CircleCI: https://circleci.com/docs/2.0/yarn/

#...
      - restore_cache:
          name: Restore Yarn Package Cache
          keys:
            - yarn-packages-{{ checksum "yarn.lock" }}
      - run:
          name: Install Dependencies
          command: yarn install
      - save_cache:
          name: Save Yarn Package Cache
          key: yarn-packages-{{ checksum "yarn.lock" }}
          paths:
            - ~/.cache/yarn
#...

Esto nunca funcionará porque yarn.lock puede cambiar, cuando no debería.

Para su información, en yarn 1.10.1 bajo macOS 10.13.6, acabo de probar el estímulo de error del OP y descubrí que yarn.lock no cambió. En otras palabras, cuando lo intenté:

yarn init
yarn add cordova
cp yarn.lock yarn.lock.initial
rm -r node_modules
yarn install
diff yarn.lock.initial yarn.lock

Entonces, al usar el hilo 1.10.1, yarn install no cambió yarn.lock , como lo había hecho para el OP cuando se usó el hilo 1.0.1. (Considero que esto es algo bueno, como creo que lo haría el OP).

@dtgriscom ¡ Es genial que el problema ya no le ocurra a Cordova! Me pregunto si se ha solucionado por completo o si el hilo aún podría intentar optimizar el archivo de bloqueo en la instalación.

Sería bueno saberlo, ¿no? Observó que el problema era específico del paquete; tiene sentido que también sea específico de la versión. (Nunca escuché una justificación para "queremos cambiar algo que no debería cambiar"; aparte de "estamos optimizando" ...)

Estoy totalmente de acuerdo en que una operación install debe ser determinista por defecto. La actualización de un archivo .lock debería requerir que el desarrollador realice una acción que sabe que producirá un cambio en el archivo. Por ejemplo, podría ejecutar algo como yarn install --optimize que permitiría una pequeña optimización que no rompa el estado actual de los paquetes.

Agregar opciones separadas que tengo que buscar en la documentación solo para tener la certeza de que mi archivo de bloqueo está intacto sin mi permiso es bastante confuso, especialmente si pueden causar fallas. Como desarrollador, espero tener control sobre las herramientas que uso y siento que este comportamiento me lo quita.

Por favor, reconsidere cambiar el comportamiento predeterminado para no modificar el archivo de bloqueo y operar únicamente en él al instalar dependencias. Una verificación de integridad con una advertencia de que package.json está sincronizado con el archivo de bloqueo es realmente todo lo que la gente necesita.

Le he estado diciendo a la gente que los PR, incluidos los cambios en el archivo de bloqueo, no se fusionarán, ya que el archivo de bloqueo solo se cambia al agregar nuevas o actualizar dependencias. Esto es lo que dice la

yarn install

Instale todas las dependencias enumeradas dentro de package.json en la carpeta local node_modules .

El archivo yarn.lock se utiliza de la siguiente manera:

• Si yarn.lock está presente y es suficiente para satisfacer todas las dependencias enumeradas en package.json , se instalan las versiones exactas registradas en yarn.lock y yarn.lock cambiarán . Yarn no buscará versiones más nuevas.
• Si yarn.lock está ausente, o no es suficiente para satisfacer todas las dependencias enumeradas en package.json (por ejemplo, si agrega manualmente una dependencia a package.json ), Yarn busca el las versiones más recientes disponibles que satisfacen las restricciones en package.json . Los resultados se escriben en yarn.lock .

Si desea asegurarse de que yarn.lock no se actualice, use --frozen-lockfile .

¿La documentación es incorrecta, ya que existen estas optimizaciones que pueden ocurrir indicadas anteriormente o es un error a tener en cuenta por el momento?

PD. todavía sucede, y yarn --frozen-lockfile no falla cuando lo hace.

Actualmente estoy usando --frozen-lockfile en mi archivo .yarnrc , que efectivamente evita que el hilo modifique el archivo yarn.lock al ejecutar yarn install en diferentes máquinas. Pero esto también evita que yarn add blahblah modifique mi yarn.lock. ¿Es ese el comportamiento correcto o me falta algo? He leído todo el hilo y me parece que --frozen-lockfile es el enfoque recomendado por ahora.

@konekoya Sí, tiene razón en que actualmente DEBE usar

yarn install --frozen-lockfile

y no puede confiar en la configuración en .yarnrc ya que evitará que su yarn.lock se actualice.

Dependiendo del contenido de sus .npmrc y .yarnrc es posible que pueda usar

yarn install --no-default-rc {dependency}

pero no confiaría en eso (ya que se rompería tan pronto como tenga otras configuraciones en sus archivos rc).

Vea mi comentario y el tema relevante: # 4570, esp. mi conclusión .

Gracias por aclarar eso @ k0pernikus. Usted acaba de hacer mi día :)

@BYK ¿ yarn.lock en yarn install lugar de cuando se ejecutan add / upgrade ?

Creo que el comentario de @ spencer-brown aquí es clave para "solucionar" este problema. Solo probé por mí mismo y ejecuté yarn upgrade y luego yarn Me dijeron "Ya actualizado". Así que eliminé mi node_modules y ejecuté yarn que luego resultó en el archivo de bloqueo "optimizado" que los otros desarrolladores de mi proyecto habrían terminado si hubiera empujado el que obtuve de yarn upgrade .

Ahora bien, si yarn upgrade (y yarn add ) ejecutaran la misma optimización que yarn install , no tendríamos este problema en primer lugar. Se ha hablado mucho de no querer romper ninguna funcionalidad existente y no veo que ejecutar la optimización después de yarn upgrade y yarn add rompa algo, solo que lo hace un poco más lento.

Como solución alternativa, estoy pensando en instruir a todos nuestros desarrolladores para que eliminen node_modules siempre que necesiten actualizar el archivo de bloqueo para forzar la "optimización" antes de enviar los archivos de bloqueo a otros. O tal vez puedan ejecutar yarn upgrade && yarn prune , ¿tal vez eso funcionaría?

Como solución alternativa, estoy pensando en instruir a todos nuestros desarrolladores para que eliminen node_modules siempre que necesiten actualizar el archivo de bloqueo para forzar la "optimización" antes de enviar los archivos de bloqueo a otros. O tal vez puedan ejecutar yarn upgrade && yarn prune , tal vez eso funcione

Actualización: no puede ejecutar prune manualmente, solo recibe este mensaje: _ "El comando prune no es necesario. yarn install eliminará los paquetes extraños" ._ Y dado que tampoco puede ejecutar la instalación son _ "Ya actualizados" _ Supongo que vamos a eliminar node_modules y luego ejecutar yarn para hacer la poda.

Para mí, el mayor punto de venta de yarn es el comportamiento del archivo de bloqueo predecible y confiable. Cambiar el archivo de bloqueo en yarn install me produce verdadera ansiedad.

Para mí, el mayor punto de venta de yarn es el comportamiento del archivo de bloqueo predecible y confiable. Cambiar el archivo de bloqueo en yarn install me produce verdadera ansiedad.

El archivo de bloqueo se presenta como una especificación exacta de lo que se instalará, para que no tengamos que preocuparnos por lo que se instalará. Utilice el mismo archivo de bloqueo y obtendrá la misma instalación cada vez. Pero a veces yarn , por iniciativa propia, por sus propias razones y sin previo aviso, cambiará el contenido del archivo de bloqueo. Sí, puede argumentar que "los cambios del archivo no cambian lo que se instalará", pero ¿por qué tomar una garantía tan clara y confundirlo? ¿Por qué me pregunto si debería volver a confirmar el archivo de bloqueo modificado? ¿Por qué mancillar tu principal reclamo de fama?

Esto es realmente increíble. Otros ya lo han dicho bien. Un archivo de bloqueo no debería cambiar durante la instalación. Esto impacta negativamente en los flujos de trabajo de los compromisos. Todos los desarrolladores de nuestro equipo saben bajo qué circunstancias se permite cambiar el archivo de bloqueo. Cuando un archivo de bloqueo cambia sin que se actualicen las dependencias, se produce una confusión innecesaria y una comprobación adicional. Esta es la UX básica del administrador de paquetes que simplemente está rota. Por favor, arregla.

Me sorprendió este comportamiento, al pasar de Node.js 13 a 14, todos mis archivos yarn.lock cambiaron al hacer un yarn install y me preguntaba por qué ...

Creo que el comportamiento apropiado sería emitir una advertencia si _optimizando_ el archivo yarn.lock de alguna manera.