Comment remplacer les dépendances imbriquées avec 'yarn'?

Si mon paquet a ces dépendances

{ "name": "my-package",
  "dependencies": { "foobar":"~1.0.3", "baz":"2.0.9" }

Et le paquet foobar a ces dépendances

{ "name": "foobar",
  "dependencies": { "baz":"^2.0.0" }

Et le plus récemment publié la version de baz est 2.1.0, la première exécution de yarn installera baz@2.1.0 dans foobar/node_modules.

Comment forcer yarn à utiliser le paquet baz@2.0.9 pour foobar?

Ma compréhension est que cela serait possible en utilisant npm shrinkwrap (a la cette question ).


Le résumé de ma question est probablement: yarn creates installations déterministes reproductibles, mais comment personnaliser cette installation?

41
demandé sur Community 2016-10-24 23:06:14

3 réponses

Si vous avez en fait une sous-dépendance qui est trop restrictive dans les versions qu'elle acceptera, vous pouvez les remplacer en utilisant yarn. Il semble que la question initiale n'était pas tout à fait correcte, mais la question initiale était en fait celle que je voulais répondre, et j'ai trouvé une réponse, donc la voici pour la postérité:

J'utilise le socket.io bibliothèque, et il a component-emitter comme dépendance. Mais il a une paire de versions dont il a besoin. C'est ce que le fils.verrouiller le fichier on dirait avant que je change quoi que ce soit:

component-emitter@1.1.2:
  version "1.1.2"
  resolved "https://registry.yarnpkg.com/component-emitter/-/component-emitter-1.1.2.tgz#296594f2753daa63996d2af08d15a95116c9aec3"

component-emitter@1.2.0:
  version "1.2.0"
  resolved "https://registry.yarnpkg.com/component-emitter/-/component-emitter-1.2.0.tgz#ccd113a86388d06482d03de3fc7df98526ba8efe"

Donc, il incluait deux copies de l'émetteur de composant dans mon code client. J'ai regardé, et il ne semblait pas y avoir de changements de rupture entre 1.1.2 et 1.2.0 (ou 1.2.1, qui était en cours). J'ai d'abord essayé en changeant simplement le fil.verrouiller le fichier:

component-emitter@1.2.1, component-emitter@^1.2.1, component-emitter@1.1.2:
  version "1.2.1"
  resolved "https://registry.yarnpkg.com/component-emitter/-/component-emitter-1.2.1.tgz#137918d6d78283f7df7a6b7c5a63e140e69425e6"

Cela a fonctionné, mais le fichier a des avertissements à propos de sa génération automatique, ce qui signifie que chaque mise à jour ou nouveau paquet que j'ajoute va piétiner sur ce changement. Un peu de recherche a trouvé le yarn --flat option, qui forcera yarn à ne pas choisir plus d'un paquet dans l'ensemble du projet. Cela me semble exagéré, car je suis sûr qu'il y a des cas réels d'incompatibilité entre les paquets plus anciens et plus récents. Je voulais juste éliminer un paquet redondant de mon code client, pour rendre le téléchargement plus petit; je veux toujours que les paquets de développement fonctionnent correctement.

, Mais dans les docs de fils --plat, j'ai trouvé une référence à un "résolutions" bloc peut aller dans le paquet.json:

"resolutions": {
  "package-a": "2.0.0",
  "package-b": "5.0.0",
  "package-c": "1.5.2"
}

J'ai donc essayé de mettre "component-emitter" : "1.2.1" dans un nouveau bloc" résolutions " dans mon paquet.json, et en fait, il a aplati le composant-émetteur à 1.2.1 pour tous les endroits qui l'ont requis, et maintenant je n'ai qu'une seule copie dans mon code client.

Mise à jour EDIT: Yarn maintenant, à partir de 1.0, prend officiellement en charge le bloc "résolutions" ci-dessus. Donc, juste l'utiliser.

50
répondu SomeCallMeTim 2017-09-07 16:15:51

Ceci est maintenant possible avec la fonction de résolution de version sélective de yarn .

Dans package.json de votre projet, utilisez resolutions:

  "resolutions": {
    "foobar/**/baz": "2.0.9"
  }

Cela remplace la version de baz du paquet foobar (et tous les autres paquets qui s'y trouvent), ce qui le force à être la version 2.0.9.

19
répondu Tom Hale 2017-10-07 01:39:46

@la réponse de SomeCallMeTime est géniale et nous le faisons depuis un mois au travail.

Malheureusement, ce n'est plus possible depuis la v0.24.x (voir que commentaire).

Il y a un PR ouvert sur Github avec une proposition RFC pour avoir un moyen simple de gérer ce cas d'utilisation sans avoir à garder un œil sur le fichier de verrouillage généré.

4
répondu maxime1992 2017-05-23 07:08:02