@chinesedfan ¿Has probado yarn upgrade-interactive ?

@milesj Sí, da el mismo resultado y también actualicé los pasos de reproducción en la descripción del problema.

Esto se debe a que yarn add [email protected] establece su paquete.json en _exactamente_ la versión 1.0.0 que solicitó.

yarn upgrade respeta su rango de semver de package.json, y dado que especificó exactamente la versión 1.0.0, no ofrecerá actualizar a otras versiones.

Podrías resolver esto de un par de maneras:

• yarn upgrade --latest ignorará el rango de semver y verá lo que está etiquetado como latest en el registro.
• cambie package.json para aceptar un rango de versión como ^1.0.0 y luego yarn upgrade (es posible que primero tenga que yarn install para actualizar el archivo de bloqueo para el rango modificado)
• especifique explícitamente una versión para upgrade , como yarn upgrade [email protected] o yarn upgrade is-alphanumerical@^1.0.0

Editar:

Lo siento, acabo de notar que hay diferentes nombres de paquetes. alphanumerical y alphabetical se ven iguales de un vistazo :)

Correcto, dado que no hay actualización para is-alphanumerical , el árbol de dependencias no se recorre más profundamente para manejar sus dependencias transitivas.

Puede intentar agregar el indicador --force y ver si eso lo convierte en las subdependencias. De lo contrario, creo que tiene razón, no hay una manera fácil de hacerlo que no sea yarn remove is-alphanumerical y yarn add is-alphanumerical

@rally25rs ¡ Gracias por tu respuesta! Probé 2 casos más.

• yarn upgrade is-alphabetical --force tampoco funciona.
• yarn upgrade is-alphanumerical actualizará TODAS sus subdependencias incluso si ya es la última.
  
  
  
  • Pero si solo quiero actualizar una subdependencia específica, todavía no es muy conveniente.
  
  

sí, este es un gran problema con el hilo en este momento. y ya está en discusión en el #2394

duplicado #2394

Por favor, vuelva a abrir: no está duplicado.

2394 describe la duplicación del paquete meck-test-bb (dependencia indirecta):

Tengo dos copias de meck-test-bb

Este problema describe solo la capacidad de actualizar la dependencia indirecta (de alguna manera).

@rally25rs Perdóname por hacer ping.

@rally25rs , por favor, ha cerrado ambos problemas sin duplicación, está mal. ¡Danos la capacidad de actualizar las dependencias indirectas, por favor!

Lo siento, hubo cierta confusión sobre el otro tema. Originalmente pensé que 2394 estaba solicitando una forma de actualizar una dependencia transitiva usando un indicador --deep , o algo así, así que marqué este problema como un duplicado de eso. Más tarde, después de volver a leer 2394, creo que se trata de algo diferente, que no es un duplicado de esto como pensé originalmente.

+1 para esta solicitud de función. También un ejemplo para cualquier tonto como yo que necesite actualizar una dependencia indirecta específica de forma manual en el ínterin:

Dada la dependencia explícita jsonwebtoken ha resuelto la dependencia implícita jws^3.0.0 a jws=3.1.4 vulnerable: y necesita que se resuelva en 3.1.5 parcheado:

Elimine la entrada jws , por ejemplo, a continuación de yarn.lock, y vuelva a ejecutar yarn . La dependencia indirecta y los paquetes afectados se actualizarán, sin tocar otras cosas (al menos en yarn v1.3)

jws@^3.0.0, jws@^3.1.4:
  version "3.1.4"
  resolved "https://registry.npmjs.org/jws/-/jws-3.1.4.tgz#f9e8b9338e8a847277d6444b1464f61880e050a2"
  dependencies:
    base64url "^2.0.0"
    jwa "^1.1.4"
    safe-buffer "^5.0.1"

Editar: puntuación

@alex-thewsey-ibm, ¡gracias por la solución!

Trabajó en hilo v1.7.

ty, trabajado Hilado 1.9.2

Podría ayudar a empujar hilo con dependencia selectiva resolutions , incluso si es para una sola dependencia. ¡Gracias a @remolueoend por la pista!
https://yarnpkg.com/lang/en/docs/selective-version-resolutions/

De los documentos:

{
  "name": "project",
  "version": "1.0.0",
  "dependencies": {
    "left-pad": "1.0.0",
    "c": "file:../c-1",
    "d2": "file:../d2-1"
  },
  "resolutions": {
    "d2/left-pad": "1.1.1",
    "c/**/left-pad": "1.1.2"
  }
}

Necesitamos esta característica en Autoprefixer para sugerir a los usuarios cómo actualizar caniuse-lite en su yarn.lock https://github.com/postcss/autoprefixer/issues/1184

El mismo problema aqui. Esperaba que yarn upgrade caniuse-lite browserslist actualizara la subdependencia. No hizo eso, ni me dio un mensaje de error diciendo que no puede actualizarlo porque no es una dependencia.

Eliminar las entradas relevantes del archivo de bloqueo y luego volver a ejecutar yarn como sugirió @alex-thewsey-ibm solucionó el problema inmediato para mí.

Es extraño para mí que al hilo le falte esta característica. Soy nuevo en yarn (y npm), así que asumí que debe haber una manera de hacer esto. Todavía no estoy completamente seguro de si hay una forma no obvia de hacer esto que nadie en este hilo conoce, o si realmente no hay forma de hacerlo.

Si realmente no hay forma de actualizar una dependencia transitiva/indirecta en el archivo de bloqueo sin agregarlo a package.json... No entiendo cómo se las arreglan los usuarios de yarn sin él.

En mi opinión, este es un comportamiento inesperado: intenté actualizar lodash recientemente con yarn upgrade [email protected] y aún no se ha actualizado para ninguna dependencia transitoria.

Todavía me quedaban todas las versiones major (^4.XX) y patch (~4.17.X) que apuntaban a la versión anterior.

La única forma de solucionarlo es mediante la edición manual de yarn.lock y luego ejecutar yarn upgrade para consolidar los cambios. Esperaría un poco mejor de una herramienta tan ampliamente utilizada.

¿Es este error reconocido o el hilo es conservador de forma predeterminada y se espera que edite manualmente yarn.lock o use alguna bandera?

Sospecho que tengo que resolver la misma alerta de seguridad que @Machiaweliczny ;) Sería realmente útil anular la dependencia indirecta mientras esperamos que los proyectos arreglen los suyos. Incluso con proyectos altamente receptivos, hay un retraso en la espera de correcciones y lanzamientos.

De hecho, esto es problemático para los problemas de seguridad en las dependencias indirectas, y la solución alternativa de editar yarn.lock , si bien es efectiva, es decepcionante y difícil de automatizar. Si este no es el comportamiento predeterminado por alguna razón, sería genial agregar una opción como --include-indirect que obligará a Yarn a seguir las dependencias indirectas.

No creo que deba necesitar una opción, no veo por qué yarn upgrade [an indirect dependency] no solo actualiza el yarn.lock a la última versión de la dependencia indirecta que permite el árbol de dependencia, sin necesidad de opciones adicionales. Creo que en este momento es solo un no-op.

Sin embargo, otra solución con la que estoy satisfecho es agregar resolutions a mi paquete.json. Si lodash es una dependencia indirecta y sé que necesito que sea >= 4.7.13 para evitar una vulnerabilidad de seguridad, puedo agregar a mi paquete.json:

  "resolutions": {
    "lodash": ">= 4.17.13"
  }

Luego simplemente ejecute yarn install , actualizará yarn.lock para cumplir con ese requisito, o se quejará si no puede porque entra en conflicto con una dependencia indirecta.

En realidad, esto parece haber funcionado bastante bien en mi caso; Me pregunto si no es una "solución alternativa", sino la solución prevista. Sin embargo, me tomó un tiempo descubrirlo. Y no entiendo las cosas lo suficientemente bien como para estar seguro de que esta es una solución universal/correcta o si podría haber algún problema en algunos casos. Si es la solución 'correcta' para actualizar las dependencias indirectas, fue algo difícil de encontrar.

¿Por qué no yarn instala la dependencia transitiva que desea actualizar pero no confirma los cambios de package.json, solo el yarn.lock?

¿Por qué no yarn instala la dependencia transitiva que desea actualizar pero no confirma los cambios de package.json, solo el yarn.lock?

No creo que eso funcione (¿siempre?), porque yarn felizmente instalará múltiples versiones del mismo paquete, incluso si una sola versión satisface todos los rangos de semver relevantes. Entonces esto instalaría la versión que desea, pero no eliminaría la versión que no desea.

@djmitche Cierto. Deberá instalar la versión dentro del rango esperado. No es ideal y es un poco tedioso, pero es un recurso provisional disponible por ahora.

@djmitche De hecho, esto es problemático para los problemas de seguridad en las dependencias indirectas, y la solución alternativa de editar yarn.lock , si bien es efectiva, es decepcionante y difícil de automatizar.

Esta es otra solución que es un poco más automatizable:

yarn remove is-alphanumerical
yarn add is-alphanumerical

Usando el ejemplo en la descripción de relaciones públicas, esto eliminaría el nivel superior y luego lo volvería a agregar, lo que obtendrá todos sus subdepósitos más recientes, de acuerdo con los rangos especificados por is-alphanumerical (intervalos de intercalación, por ejemplo) . Luego producirá un nuevo archivo de bloqueo.

El efecto secundario es que actualizará todos los subdepartamentos, lo que no es lo ideal. Para un problema de seguridad en el subdepartamento A, me gustaría actualizar solo el subdepartamento A.

La solución alternativa de agregar el subdep A como un dep directo solo para solucionar un problema de seguridad es peor porque crea confusión (el paquete no se usa directamente), así como una carga de mantenimiento.

hilo eliminar es-alfanumérico
hilo agregar es-alfanumérico

Esta parece ser la única forma confiable de actualizar una dependencia. Hoy me di cuenta de que estábamos atascados en una versión 1.0.0 de un paquete que se había actualizado a 1.1.0 hace un año. El paquete que estábamos usando usaba ^1.0.0 y todas las veces que "actualizamos" ese paquete, nunca tomó la nueva versión 1.1.0 de su dependencia.
Resultó que había un error bastante grave que fallaba silenciosamente en nuestro producto y que debería haberse solucionado hace un año sin que yo desperdiciara un día investigando por qué teníamos este problema.

No puedo creer que editar yarn.lock manualmente, eliminar y volver a agregar el paquete o usar la resolución selectiva sean las "formas" de actualizar una dependencia indirecta.

En mi opinión, yarn upgrade debería actualizar las dependencias indirectas a la última versión aceptada del servidor, por eso actualizamos un paquete. Quiero decir, si hubiera una ruptura en el rango de semver, actualizaría las dependencias indirectas, por lo que debería hacerlo siempre.

¿Sería útil escribir algún tipo de script externo para hacer esto? Supongo que simplemente eliminaría todas las entradas yarn.lock para el paquete dado y luego volvería a ejecutar yarn.

Hay un script simple para hacer esto: https://gist.github.com/pftg/fa8fe4ca2bb4638fbd19324376487f42

¿Puede uno de los mantenedores cambiar la etiqueta de cat-feature a cat-bug ?

¿Puede uno de los mantenedores cambiar la etiqueta de cat-feature a cat-bug?

¿Por qué? esto no es un error. Es como está diseñado. yarn upgrade nunca tuvo la intención de usarse para actualizar una dependencia transitiva. El "problema" abierto originalmente incluso se etiqueta como una solicitud de función.

Internamente upgrade usa yarn outdated para determinar qué está desactualizado y a qué versiones actualizar. outdated solo verifica las dependencias directas.

Podría estar equivocado, o tal vez haya cambiado, pero estoy bastante seguro de que npm upgrade al menos hace 3 años cuando yarn upgrade se modificó por última vez, tampoco proporciona una forma de actualizar una dependencia transitiva. (nuevamente, eso podría haber cambiado ya que a lo largo de los años, no estoy muy actualizado sobre los cambios de npm).

Cualquiera es libre de enviar un PR para agregar esta funcionalidad. Este es un proyecto de código abierto y depende de la comunidad en general contribuir. Esta solicitud de función ha estado abierta durante años, pero nadie ha dado un paso adelante para implementarla y es por eso que no se ha "arreglado".

@nnmrts , ¿podría consultar mi secuencia de comandos https://github.com/yarnpkg/yarn/issues/4986#issuecomment -562719589? ¿Te ayudará por ahora?

@rally25rs Lo siento, estaba cansado y malhumorado, considero mi comentario como resuelto. 😬

@nnmrts , ¿podría consultar mi script n.º 4986 (comentario) ? ¿Le ayudará por ahora?

Desafortunadamente, ese script no funcionó para mí, lo probé ayer. Tal vez hice algo mal, pero el script "vació" todo mi archivo yarn.lock.

No estoy seguro de cuán buena es esta solución, pero ejecuté este script que escribí:

const fs = require('fs')
const lockfile = require('@yarnpkg/lockfile')
const package = require('./package.json')

const lock = lockfile.parse(fs.readFileSync('yarn.lock', 'utf-8')).object

const allDeps = new Set()

const parseDep = ([name, version]) => {
  allDeps.add(`${name}@${version}`)
}

Object.entries(package.dependencies).forEach(parseDep)
Object.entries(package.devDependencies).forEach(parseDep)

const newLock = Object.fromEntries(Object.entries(lock).filter(([dep]) => allDeps.has(dep)))
const newLockString = lockfile.stringify(newLock)

fs.writeFileSync('yarn.lock', newLockString)

Luego ejecutó yarn install y parece instalar las últimas versiones de dependencias indirectas.

Pude resolver las dependencias profundas/indirectas con éxito. Me pregunto cuándo obtendremos un apoyo oficial.

https://medium.com/@ayushya/upgrading-javascript-packages-deep-dependencies-using-yarn-8b5983d5fb6b

He intentado resolver y explicar los riesgos de volver a generar el yarn.lock y he sugerido lo que se debe hacer.

Avíseme si esto también funciona para ustedes. O cualquier sugerencia para mejorar el proceso de actualización.

@ayushya Hm, eso parece funcionar, genio.

Me pregunto si yarn aceptaría un parche en el que yarn upgrade a una dependencia indirecta (¿o algún otro comando?) simplemente... ¿hizo eso?

@jrochkind Hubiera esperado un yarn upgrade de una dependencia indirecta para actualizarlo incluso si no es mi dependencia directa. Sin esa función, puede retrasarse años en las actualizaciones de las dependencias indirectas.

En mi caso, estaba tratando de actualizar fsevents , para que no arrojara errores cuando hice yarn install (https://github.com/fsevents/fsevents/issues/278 ). fsevents no es un paquete que uso directamente, es algo que usa webpack-dev-server . Pero, sorprendentemente, estaba bloqueado en cualquier versión que existiera cuando webpack-dev-server se instaló por primera vez en esta aplicación.

Tuve que usar este truco para actualizarlo, lo que parecía un truco total. https://github.com/yarnpkg/yarn/issues/4986#issuecomment-395036563

la solución no funciona para mí, desafortunadamente, las antiguas dependencias profundas se agregaron nuevamente al archivo yarn.lock después de eliminarlas. Puedo verlos en la carpeta node_modules y en el archivo yarn.lock después de ejecutar yarn install.

¿Quizás la solución alternativa no es compatible con los espacios de trabajo de hilo?

@FelipeLujan cuando la solución funciona, las dependencias profundas aún se agregan nuevamente al archivo yarn.lock, eso se espera, pero con nuevas versiones posteriores. Pero solo con nuevas versiones si hay nuevas versiones publicadas y si están permitidas por el árbol de dependencia. Si alguna dependencia intermedia expresa una restricción que no permite una actualización, aún no se pueden actualizar. Solo se actualizan a lo último permitido por las restricciones en el árbol.

Sin embargo, no uso espacios de trabajo de hilo, por lo que no puedo decir si eso es relevante.

@FelipeLujan AFAIK los espacios de trabajo de hilo funcionan de manera similar.

La solución alternativa para eliminar la sección del paquete solo actualizará el paquete a la última versión MENOR/PARCHE .
Si desea actualizar el paquete a una versión PRINCIPAL más nueva, debe encontrar la cadena de dependencia del paquete que ejecuta yarn why package-name-here y actualizar el paquete en la parte superior de su cadena.

PRECAUCIÓN: pruebe su código, ya que actualizar los paquetes a una versión PRINCIPAL más nueva puede traer algunos cambios importantes.

https://github.com/djmitche/yarn-minify podría ayudar con esto...

La solución alternativa de @ayushya funciona muy bien para mí, editando manualmente yarn.lock para eliminar una dependencia indirecta, luego ejecutando yarn install para volver a agregarlo en una versión posterior.

Sin embargo, para mí, esto parece una característica que debería estar integrada en yarn, en lugar de requerir que edites manualmente yarn.lock. Parece que debería ser bastante sencillo crear una característica que es como si hubiera editado manualmente para eliminar la dependencia y ejecutar la instalación de hilo. Siento que esta característica realmente debería estar integrada en yarn, y estoy un poco confundido en cuanto a por qué no lo está.

Pude resolver las dependencias profundas/indirectas con éxito. Me pregunto cuándo obtendremos un apoyo oficial.

https://medium.com/@ayushya/upgrading-javascript-packages-deep-dependencies-using-yarn-8b5983d5fb6b

He intentado resolver y explicar los riesgos de volver a generar el yarn.lock y he sugerido lo que se debe hacer.

Avíseme si esto también funciona para ustedes. O cualquier sugerencia para mejorar el proceso de actualización.

Creo que es la misma resolución dada por @ alex-thewsey-ibm. Eliminar esa dependencia particular de yarn.lock me ayudó.
De todos modos, gracias por este truco ☺️

Usar resolutions en package.json me funcionó https://github.com/webpack/webpack-dev-server/issues/2739#issuecomment -695164486

Esto debería al menos devolver alguna advertencia:

yarn add [email protected]
yarn upgrade is-alphabetical

Esto es lo que obtengo en su lugar:

success Saved lockfile.
success Saved 0 new dependencies.

No hay cambios en package.json y yarn.lock aunque hay una nueva versión del paquete is-alphabetical disponible.