Yarn: Agregar una nueva dependencia no respeta la restricción de versión existente en la resolución
¿Quieres solicitar una función o informar de un error ?
Bicho.
¿Cuál es el comportamiento actual?
Yarn no respeta los bloqueos de versiones ya agregados al resolver las dependencias de las dependencias recién agregadas.
Si el comportamiento actual es un error, proporcione los pasos para reproducirlo.
- Iniciar un módulo vacío
- Agregar reaccionar 15.6.1
yarn add [email protected] - Agregar [email protected]
yarn add [email protected] - El error se reproduce y se instalan dos versiones diferentes de reacción:
$ yarn list react
yarn list v1.1.0
├─ [email protected]
└─ [email protected]
└─ [email protected]
✨ Done in 0.24s.
¿Cuál es el comportamiento esperado?
Se esperaba que solo se instalara [email protected] ya que puede cumplir con todas las restricciones de versión. Esto es lo que sucede si elimino yarn.lock después de que ambas dependencias estén en package.json y yarn install ie
$ rm -rf node_modules/ yarn.lock && yarn install && yarn list react
yarn list v1.1.0
└─ [email protected]
✨ Done in 0.17s.
Por favor, mencione su versión de node.js, yarn y sistema operativo.
$ node --version
v6.9.4
$ yarn --version
1.2.0
$ system_profiler SPSoftwareDataType|grep "System Version"
System Version: macOS 10.12.6 (16G29)
EDITAR: La reproducción original se hizo con hilo v.1.1.0, pero actualicé a 1.2.0 y esto se reproduce todavía.
hniirane
Todos 4 comentarios
Estoy investigando esto ...
Observar que los parámetros pasados a PackageResolver.getHighestRangeVersionMatch(name, range, manifest) pueden ser incorrectos. El range pasado parece ser la versión única resuelta real ( 15.6.2 ) en lugar del rango solicitado ( ^15.5.4 ).
Eso, a su vez, se acumula hasta la línea donde verifica si alguna versión instalada actual coincide con el rango de semver: semver.maxSatisfying(["15.6.1"], '15.6.2'); // null Si se hubiera pasado el rango correcto, entonces se habría ejecutado semver.maxSatisfying(["15.6.1"], '^15.5.4'); // 15.6.1 que debería resolver este problema.
Continuaré retrocediendo a través del código ...
rally25rs
en 11 oct. 2017
OK, parece que esto fue introducido por # 3729 específicamente la línea en package-request.js :
const solvedRange = semver.validRange(range) ? info.version : range;
Entonces, si el rango ( ^15.5.4 ) es válido, entonces usamos info.version lugar ( 15.6.2 ).
Eso se transmite para ver si alguna versión instalada coincide con 15.6.2 :
const maxValidRange = semver.maxSatisfying(['15.6.1'], '15.6.2'); // null
@arcanis , parece que ese PR vinculado era tuyo. Dudo en cambiar algo y arriesgarme a reabrir lo que sea que haya arreglado ese PR. ¿Podrías echar una mano?
rally25rs
en 11 oct. 2017
Analizaré esto hoy 👍
arcanis
en 16 oct. 2017
¡Intentemos arreglar eso! No me gusta que los paquetes están confiando en elevación (recuerda mis palabras - incluso si podemos solucionar este problema, van a romper de nuevo en el futuro), pero nosotros lo que es menos eficiente de lo que podría ser no es grande tampoco. Volviendo a publicar lo que puse en # 5561:
Realmente no entiendo la lógica anterior. si el rango es un semver válido, ¿no lo usa?
Tienes razón, eso no tiene mucho sentido: / Creo que lo que quería hacer era "si esta no es una versión sino un rango, entonces usa la que ya tenemos si es posible" (ya que el objetivo del PR era no hacer optimización al leer del archivo de bloqueo). Como tal, la condición probablemente debería ser:
const solvedRange = semver.valid(range) && !semver.validRange(range) ? range : info.version;
Temas relacionados
davidmaxwaterman
·
3Comentarios
seansfkelley
·
3Comentarios
MunifTanjim
·
3Comentarios
AzGoalie
·
3Comentarios
victornoel
·
3Comentarios
Comentario más útil
Analizaré esto hoy 👍