@chinesedfan Avez-vous essayé yarn upgrade-interactive ?

@milesj Oui, cela donne le même résultat et j'ai également mis à jour les étapes de reproduction dans la description du problème.

En effet, yarn add [email protected] définit votre package.json sur la version _exactement_ 1.0.0 comme vous l'avez demandé.

yarn upgrade respecte votre plage de semver package.json, et puisque vous avez spécifié exactement la version 1.0.0, il ne proposera pas de mise à niveau vers d'autres versions.

Vous pouvez résoudre ce problème de plusieurs manières :

• yarn upgrade --latest ignorera la plage semver et verra ce qui est étiqueté comme latest dans le registre.
• modifiez package.json pour accepter une plage de versions comme ^1.0.0 puis yarn upgrade (vous devrez peut-être d'abord yarn install pour qu'il mette à jour le fichier de verrouillage pour la plage modifiée)
• spécifiez explicitement une version de upgrade , comme yarn upgrade [email protected] ou yarn upgrade is-alphanumerical@^1.0.0

Éditer:

Désolé, je viens de remarquer qu'il existe différents noms de packages. alphanumerical et alphabetical se ressemblent en un coup d'œil :)

Bon, puisqu'il n'y a pas de mise à niveau pour is-alphanumerical , l'arborescence des dépendances n'est pas parcourue plus profondément pour gérer ses dépendances transitives.

Vous pouvez essayer d'ajouter le drapeau --force et voir si cela en fait des sous-dépendances. Sinon, je pense que vous avez raison, il n'y a pas de moyen facile de le faire autre que yarn remove is-alphanumerical et yarn add is-alphanumerical

@rally25rs Merci pour votre réponse ! J'ai testé 2 autres cas.

• yarn upgrade is-alphabetical --force ne fonctionne pas non plus.
• yarn upgrade is-alphanumerical mettra à jour TOUTES ses sous-dépendances même si elle est déjà la plus récente.
  
  
  
  • Mais si je veux juste mettre à niveau une sous-dépendance spécifiée, ce n'est toujours pas très pratique.
  
  

oui, c'est un problème majeur avec le fil en ce moment. et c'est déjà en discussion au #2394

duplicata #2394

S'il vous plaît, rouvrez: ce n'est pas un doublon.

2394 décrit la duplication du package meck-test-bb (dépendance indirecte) :

J'ai deux copies de meck-test-bb

Ce problème décrit simplement la possibilité de mettre à niveau la dépendance indirecte (d'une manière ou d'une autre).

@rally25rs Pardonnez-moi de cingler.

@rally25rs , s'il vous plaît, vous avez fermé les deux problèmes de non-duplication, c'est faux. Donnez-nous la possibilité de mettre à jour les dépendances indirectes, s'il vous plaît !

Désolé, il y a eu une certaine confusion sur l'autre problème. Au départ, je pensais que 2394 demandait un moyen de mettre à niveau un dep transitif en utilisant un indicateur --deep , ou quelque chose comme ça, alors j'avais marqué ce problème comme un doublon de celui-ci. Plus tard, après avoir relu 2394, je pense qu'il s'agissait de quelque chose de différent, qui n'est pas un doublon comme je le pensais à l'origine.

+1 pour cette demande de fonctionnalité. Aussi un exemple pour quelqu'un comme moi qui a besoin de mettre à jour manuellement une dépendance indirecte spécifique entre-temps :

Étant donné la dépendance explicite jsonwebtoken a résolu la dépendance implicite jws^3.0.0 en vulnérable jws=3.1.4 : et vous en avez besoin pour résoudre à la place le correctif 3.1.5 :

Supprimez l'entrée jws par exemple ci-dessous de yarn.lock, et relancez yarn . La dépendance indirecte et tous les packages concernés seront mis à jour, sans toucher à autre chose (sur yarn v1.3 au moins)

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"

Edit : ponctuation

@alex-thewsey-ibm, merci pour la solution de contournement !

Travaillé sur le fil v1.7.

ty, fils travaillés 1.9.2

Peut aider à pousser le fil avec une dépendance sélective resolutions , même si c'est pour une seule dépendance. Merci à @remolueoend pour l'indice !
https://yarnpkg.com/lang/en/docs/selective-version-resolutions/

À partir de la documentation :

{
  "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"
  }
}

Nous avons besoin de cette fonctionnalité dans Autoprefixer pour suggérer aux utilisateurs comment mettre à jour caniuse-lite dans leur yarn.lock https://github.com/postcss/autoprefixer/issues/1184

Même problème ici. Je m'attendais à ce que yarn upgrade caniuse-lite browserslist mette à niveau la sous-dépendance. Il ne l'a pas fait, et il ne m'a pas non plus donné de message d'erreur disant qu'il ne peut pas le mettre à niveau parce que ce n'est pas une dépendance.

La suppression des entrées de fichier de verrouillage pertinentes, puis la réexécution de yarn comme suggéré par @alex-thewsey-ibm a résolu le problème immédiat pour moi.

Il est étrange pour moi que le fil manque de cette fonctionnalité. Je suis nouveau sur le fil (et le npm), donc je suppose qu'il doit y avoir un moyen de le faire. Je ne suis toujours pas complètement sûr s'il existe un moyen non évident de le faire qu'aucun membre de ce fil ne connaît, ou s'il n'y a vraiment aucun moyen de le faire.

S'il n'y a vraiment aucun moyen de mettre à niveau une dépendance transitive/indirecte dans le fichier de verrouillage sans l'ajouter à package.json... Je ne comprends pas comment les utilisateurs de fil s'en passent.

C'est un comportement inattendu IMO - j'ai essayé de mettre à jour lodash récemment avec yarn upgrade [email protected] et il n'a toujours pas été mis à jour pour toute dépendance transitoire.

Il me restait toujours toutes les versions major (^4.XX) et patch (~4.17.X) pointant vers l'ancienne version.

La seule façon de résoudre ce problème consiste à modifier manuellement yarn.lock , puis à exécuter yarn upgrade pour consolider les modifications. Je m'attendrais à un peu mieux d'un outil aussi largement utilisé.

Est-ce que ce bogue reconnu ou le fil est conservateur par défaut et je suis censé modifier manuellement yarn.lock ou utiliser un indicateur ?

Je soupçonne que j'ai la même alerte de sécurité à résoudre que @Machiaweliczny ;) Il serait vraiment utile de remplacer la dépendance indirecte pendant que nous attendons que les projets corrigent les leurs. Même avec des projets très réactifs, il y a un délai d'attente pour les correctifs et les versions.

En effet, cela pose problème pour les problèmes de sécurité dans les dépendances indirectes, et la solution de contournement consistant à éditer yarn.lock , bien qu'efficace, est décevante et difficile à automatiser. Si ce n'est pas le comportement par défaut pour une raison quelconque, ce serait bien d'ajouter une option comme --include-indirect qui forcera Yarn à suivre les dépendances indirectes.

Je ne pense pas qu'il devrait avoir besoin d'une option, je ne vois pas pourquoi yarn upgrade [an indirect dependency] ne met pas simplement à jour le yarn.lock à la dernière version de la dépendance indirecte autorisée par l'arbre de dépendance, sans aucun besoin de options additionelles. Je pense qu'en ce moment c'est juste un non-op?

Cependant, une autre solution de contournement qui me satisfait consiste à ajouter resolutions à mon package.json. Si lodash est une dépendance indirecte, et je sais que j'en ai besoin pour être >= 4.7.13 pour éviter une faille de sécurité, je peux ajouter à mon package.json :

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

Ensuite, exécutez simplement yarn install , il mettra à jour le yarn.lock pour répondre à cette exigence, ou se plaindra s'il ne le peut pas car il est en conflit avec une dépendance indirecte.

Cela semble en fait avoir plutôt bien fonctionné dans mon cas; Je me demande si ce n'est pas une "solution de contournement" mais la solution prévue ? J'ai mis du temps à le découvrir cependant. Et je ne comprends pas assez bien les choses pour être sûr qu'il s'agit d'une solution universelle/correcte ou s'il peut y avoir des problèmes dans certains cas. Si c'est la "bonne" solution pour mettre à niveau les dépendances indirectes, c'était un peu difficile à trouver.

Pourquoi ne pas fil installer le dep transitif que vous souhaitez mettre à jour mais ne pas valider les modifications de package.json, juste le fil.lock ?

Pourquoi ne pas fil installer le dep transitif que vous souhaitez mettre à jour mais ne pas valider les modifications de package.json, juste le fil.lock ?

Je ne pense pas que cela fonctionnera (toujours?), Parce que yarn installera volontiers plusieurs versions du même package, même si une seule version satisferait toutes les gammes de semver pertinentes. Cela installerait donc la version que vous voulez, mais ne supprimerait pas la version que vous ne voulez pas.

@djmitche Exact . Vous devrez installer la version dans la plage attendue. Pas idéal et un peu fastidieux, mais un palliatif disponible pour l'instant.

@djmitche En effet, cela pose problème pour les problèmes de sécurité dans les dépendances indirectes, et la solution de contournement consistant à éditer yarn.lock , bien qu'efficace, est décevante et difficile à automatiser.

Voici une autre solution de contournement légèrement plus automatisable :

yarn remove is-alphanumerical
yarn add is-alphanumerical

En utilisant l'exemple dans la description du PR, cela supprimerait le dep de niveau supérieur puis le rajouterait, ce qui obtiendrait tous ses derniers sous-deps, selon les plages spécifiées par is-alphanumerical (plages caret, par exemple) . Il produira alors un nouveau fichier de verrouillage.

L'effet secondaire est qu'il mettra à jour tous les sous-dépôts, ce qui n'est pas idéal. Pour un problème de sécurité dans le sous-dépôt A, je voudrais uniquement mettre à jour le sous-dépôt A.

La solution de contournement consistant à ajouter la sous-dépôt A en tant que dépôt direct juste pour résoudre un problème de sécurité est pire car elle crée de la confusion (le paquet n'est pas utilisé directement) ainsi qu'une charge de maintenance.

fil supprimer is-alphanumerical
fil ajouter est alphanumérique

Cela semble être le seul moyen fiable de mettre à jour une dépendance. J'ai réalisé aujourd'hui que nous étions bloqués sur une version 1.0.0 d'un paquet mis à jour à 1.1.0 il y a un an. Le package que nous utilisions utilisait ^1.0.0 et toutes les fois que nous avons "mis à jour" ce package, il n'a jamais récupéré la nouvelle version 1.1.0 de sa dépendance.
Il s'avère qu'il y avait un bogue assez grave qui échouait silencieusement dans notre produit et qui aurait dû être corrigé il y a un an sans que je perde une journée à chercher pourquoi nous avions ce problème.

Je ne peux pas croire que l'édition manuelle de yarn.lock, la suppression puis le rajout du package ou l'utilisation d'une résolution sélective sont les "façons" de mettre à jour une dépendance indirecte.

IMO, yarn upgrade devrait mettre à jour les dépendances indirectes vers la dernière version de semver acceptée, c'est pourquoi nous mettons à niveau un package. Je veux dire, s'il y avait une rupture dans la plage semver, cela mettrait à jour les dépendances indirectes, donc il devrait toujours le faire.

Serait-il utile d'écrire une sorte de script externe pour le faire? Je suppose que cela supprimerait simplement toutes les entrées yarn.lock pour le package donné, puis relancerait le fil?

Il existe un script simple pour le faire : https://gist.github.com/pftg/fa8fe4ca2bb4638fbd19324376487f42

L'un des mainteneurs peut-il s'il vous plaît changer l'étiquette de cat-feature à cat-bug ?

L'un des responsables peut-il changer l'étiquette de cat-feature en cat-bug ?

Pourquoi? ce n'est pas un bug. Il est tel que conçu. yarn upgrade n'a jamais été destiné à être utilisé pour mettre à niveau une dépendance transitive. Le "problème" ouvert à l'origine est même étiqueté comme une demande de fonctionnalité.

En interne, upgrade utilise yarn outdated pour déterminer ce qui est obsolète et vers quelles versions mettre à niveau. outdated ne vérifie que les dépendances directes.

Je peux me tromper, ou peut-être que cela a changé, mais je suis à peu près sûr que npm upgrade il y a au moins 3 ans, lorsque yarn upgrade a été retravaillé pour la dernière fois, ne fournit pas non plus un moyen de mettre à niveau un dep transitif. (encore une fois, cela a peut-être changé car au fil des ans, je ne suis pas trop au courant des changements de npm).

N'importe qui est libre de soumettre un PR pour ajouter cette fonctionnalité. Il s'agit d'un projet open source et c'est à la communauté dans son ensemble d'y contribuer. Cette demande de fonctionnalité est ouverte depuis des années, mais personne ne s'est mobilisé pour l'implémenter et c'est pourquoi elle n'a pas été "corrigée".

@nnmrts pourriez-vous vérifier mon script https://github.com/yarnpkg/yarn/issues/4986#issuecomment -562719589 cela vous aidera-t-il pour l'instant ?

@rally25rs Désolé, j'étais fatigué et grincheux, considérez mon commentaire comme résolu. 😬

@nnmrts pourriez-vous vérifier mon script # 4986 (commentaire) cela vous aidera-t-il pour l'instant ?

Ce script n'a malheureusement pas fonctionné pour moi, je l'ai essayé hier. J'ai peut-être fait quelque chose de mal, mais tout mon fichier yarn.lock a été "vidé" par le script.

Je ne suis pas sûr de la qualité d'une solution de contournement, mais j'ai exécuté ce script que j'ai écrit:

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)

Puis a exécuté yarn install et il semble installer les dernières versions des dépendances indirectes.

J'ai pu résoudre avec succès les dépendances profondes/indirectes. Je me demande quand nous aurons un soutien officiel.

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

J'ai essayé de résoudre et d'expliquer les risques de régénérer le yarn.lock et j'ai suggéré ce qu'il fallait faire.

Faites-moi savoir si cela fonctionne aussi pour vous. Ou des suggestions pour améliorer le processus de mise à niveau.

@ayushya Hm, cela semble fonctionner, génie.

Je me demande si le fil accepterait un patch dans lequel yarn upgrade à une dépendance indirecte (ou à une autre commande ?) juste... est-ce que ça ?

@jrochkind Je me serais attendu à un yarn upgrade d'une dépendance indirecte pour la mettre à niveau même si ce n'est pas ma dépendance directe. Sans cette fonctionnalité, vous pouvez avoir des années de retard sur les mises à jour des dépendances indirectes.

Dans mon cas, j'essayais de mettre à jour fsevents , afin qu'il ne génère pas d'erreurs lorsque j'ai fait un yarn install (https://github.com/fsevents/fsevents/issues/278 ). fsevents n'est pas un package que j'utilise directement -- c'est quelque chose que webpack-dev-server utilise. Mais étonnamment, j'étais bloqué sur la version existante lorsque webpack-dev-server a été installé pour la première fois dans cette application.

J'ai dû utiliser cette astuce pour le mettre à niveau, ce qui semblait être un hack total. https://github.com/yarnpkg/yarn/issues/4986#issuecomment -395036563

la solution de contournement ne fonctionne pas pour moi, malheureusement, les anciennes dépendances profondes ont été ajoutées à nouveau au fichier yarn.lock après les avoir supprimées. Je peux les voir dans le dossier node_modules et le fichier yarn.lock après avoir exécuté l'installation de yarn.

peut-être que la solution de contournement n'est pas compatible avec les espaces de travail de fil ?

@FelipeLujan lorsque la solution de contournement fonctionne, les dépendances profondes sont toujours ajoutées au fichier yarn.lock - ce qui est attendu - mais avec de nouvelles versions ultérieures. Mais uniquement avec les nouvelles versions si de nouvelles versions sont publiées et si elles sont autorisées par l'arborescence des dépendances. Si certaines dépendances intermédiaires expriment une restriction qui ne permet pas une mise à niveau, elles ne peuvent toujours pas être mises à niveau. Ils sont simplement mis à niveau vers la dernière version autorisée par les restrictions de l'arborescence.

Cependant, je n'utilise pas d'espaces de travail de fil, donc je ne peux pas dire si c'est pertinent.

@FelipeLujan Les espaces de travail de fil AFAIK fonctionnent de la même manière.

La solution de contournement pour supprimer la section package ne mettra à niveau le package que vers la dernière version MINOR/PATCH .
Si vous souhaitez mettre à niveau le package vers une version MAJEURE plus récente, vous devez trouver la chaîne de dépendance du package exécutant yarn why package-name-here et mettre à niveau le package au sommet de sa chaîne.

ATTENTION : testez votre code car la mise à niveau des packages vers une version MAJEURE plus récente peut entraîner des modifications avec rupture.

https://github.com/djmitche/yarn-minify pourrait aider avec ça..

La solution de contournement de @ayushya fonctionne très bien pour moi, en éditant manuellement le yarn.lock pour supprimer une dépendance indirecte, puis en exécutant yarn install pour le rajouter à une version ultérieure.

Pour moi, cela semble être une fonctionnalité qui devrait être intégrée à yarn, plutôt que de vous obliger à modifier manuellement yarn.lock. Il semble qu'il devrait être assez simple de créer une fonctionnalité comme si vous l'aviez modifiée manuellement pour supprimer la dépendance et exécuter l'installation de yarn. Je pense que cette fonctionnalité devrait vraiment être intégrée au fil, et je suis un peu confus quant à la raison pour laquelle ce n'est pas le cas.

J'ai pu résoudre avec succès les dépendances profondes/indirectes. Je me demande quand nous aurons un soutien officiel.

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

J'ai essayé de résoudre et d'expliquer les risques de régénérer le yarn.lock et j'ai suggéré ce qu'il fallait faire.

Faites-moi savoir si cela fonctionne aussi pour vous. Ou des suggestions pour améliorer le processus de mise à niveau.

Je pense que c'est la même résolution donnée par @alex-thewsey-ibm. La suppression de cette dépendance particulière de yarn.lock m'a aidé.
Quoi qu'il en soit, merci pour ce hack☺️

L'utilisation resolutions dans package.json a fonctionné pour moi https://github.com/webpack/webpack-dev-server/issues/2739#issuecomment -695164486

Cela devrait au moins renvoyer un avertissement :

yarn add [email protected]
yarn upgrade is-alphabetical

Voici ce que j'obtiens à la place :

success Saved lockfile.
success Saved 0 new dependencies.

Il n'y a aucun changement dans package.json et yarn.lock même si une nouvelle version de package is-alphabetical est disponible.