Yarn: Adicionar uma nova dependência não respeita a restrição de versão existente na resolução
Você quer solicitar um recurso ou relatar um bug ?
Inseto.
Qual é o comportamento atual?
O Yarn não respeita os bloqueios de versão já adicionados ao resolver as dependências de dependências recém-adicionadas.
Se o comportamento atual for um bug, forneça as etapas para reproduzi-lo.
- Inicie um módulo vazio
- Adicionar reagir 15.6.1
yarn add [email protected] - Adicionar [email protected]
yarn add [email protected] - O bug se reproduz e duas versões diferentes reagem são instaladas:
$ yarn list react
yarn list v1.1.0
├─ [email protected]
└─ [email protected]
└─ [email protected]
✨ Done in 0.24s.
Qual é o comportamento esperado?
Espera-se que apenas [email protected] seja instalado, pois pode cumprir todas as restrições de versão. Isso é o que acontece se eu deletar yarn.lock depois que ambas as dependências estiverem no package.json e 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.
Mencione seu node.js, yarn e versão do sistema operacional.
$ node --version
v6.9.4
$ yarn --version
1.2.0
$ system_profiler SPSoftwareDataType|grep "System Version"
System Version: macOS 10.12.6 (16G29)
EDIT: A reprodução original foi feita com yarn v.1.1.0, mas eu atualizei para 1.2.0 e reproduz ainda.
hniirane
Todos 4 comentários
Estou cavando nisso ...
Perceber que os parâmetros passados para PackageResolver.getHighestRangeVersionMatch(name, range, manifest) podem estar incorretos. O range passado parece ser a versão única resolvida real ( 15.6.2 ) em vez do intervalo solicitado ( ^15.5.4 ).
Isso, por sua vez, vai até a linha onde verifica se alguma versão atual instalada corresponde ao intervalo de sempre: semver.maxSatisfying(["15.6.1"], '15.6.2'); // null Se o intervalo correto tivesse sido passado, ele teria executado semver.maxSatisfying(["15.6.1"], '^15.5.4'); // 15.6.1 que deveria resolver este problema.
Vou continuar retrocedendo pelo código ...
rally25rs
em 11 out. 2017
OK, parece que isso foi introduzido por # 3729 especificamente a linha em package-request.js :
const solvedRange = semver.validRange(range) ? info.version : range;
Portanto, se o intervalo ( ^15.5.4 ) for válido, então usamos info.version ( 15.6.2 ).
Isso é passado para ver se alguma versão instalada corresponde a 15.6.2 :
const maxValidRange = semver.maxSatisfying(['15.6.1'], '15.6.2'); // null
@arcanis , parece que aquele PR vinculado era seu. Hesito em mudar qualquer coisa e corro o risco de reabrir o que quer que o PR tenha corrigido. Você poderia dar uma mão?
rally25rs
em 11 out. 2017
Analisarei isso hoje 👍
arcanis
em 16 out. 2017
Então, vamos tentar consertar isso! Eu não gosto que os pacotes estão confiando em elevação (marquem minhas palavras - mesmo que corrigir isso, eles vão quebrar novamente no futuro), mas nos tornando-o menos eficiente do que poderia ser não é grande também. Postando novamente o que coloquei no # 5561:
Eu realmente não entendo a lógica acima. se intervalo é um semver válido, então não o usa?
Você está certo, isso não faz muito sentido: / Acho que o que eu queria fazer era "se esta não é uma versão, mas é uma gama, então use aquela que já temos, se possível" (visto que o objetivo do PR era não fazer otimização ao ler o arquivo de bloqueio). Como tal, a condição provavelmente deve ser:
const solvedRange = semver.valid(range) && !semver.validRange(range) ? range : info.version;
Questões relacionadas
jviotti
·
3Comentários
sanex3339
·
3Comentários
catkins
·
3Comentários
ocolot
·
3Comentários
davidmaxwaterman
·
3Comentários
Comentários muito úteis
Analisarei isso hoje 👍