Yarn: Ajouter un moyen d'installer des dépendances homologues de package pour le développement / test

Créé le 27 oct. 2016  ·  72Commentaires  ·  Source: yarnpkg/yarn

Voulez-vous demander une _fonctionnalité_ ou signaler un _bug_?
Fonctionnalité

Quel est le comportement actuel?
N / A

Quel est le comportement attendu?
Fournissez une commande CLI yarn install --peer qui installera les dépendances homologues spécifiées dans package.json . De cette façon, le développement / test peut utiliser les pairs tels que react / ng2 / grunt.

cat-feature help wanted triaged

Commentaire le plus utile

+1 c'est important pour les auteurs de bibliothèques

Tous les 72 commentaires

@ jpollard-cs Je ne fais pas référence à l'ajout d'un package en tant que dépendance homologue, je fais référence au fait d'avoir un moyen d'installer tous les packages actuellement répertoriés comme dépendances homologues.
Sinon, il n'y a pas de moyen viable de développer des plugins.

npm install
Installerait tous les packages déclarés dans la section des dépendances package.json.

yarn add --peer
Je m'attendais à ce que cela installe tous les packages déclarés dans la section package.json peerDependencies.

Existe-t-il un moyen d'installer un paquet déclaré dans peerDependencies?

Mon cas d'utilisation est le développement / test d'un module natif react.

Voici le problème NPM, qu'ils ont fermé: https://github.com/npm/npm/issues/11213

Apparemment pas important pour les développeurs NPM.

+1 c'est important pour les auteurs de bibliothèques

J'ai déjà écrit ceci sur la question NPM, mais pour les gens de Yarn:

J'ai écrit un programme cli pour installer les dépendances homologues d'un paquet:

# If you're using npm
npm install -g install-peerdeps

# If you're using yarn
yarn global add install-peerdeps

cd my-project-directory

install-peerdeps <package>[@<version>]

# for example
install-peerdeps @angular/core
# will install all of angular's peerdeps

Si vous rencontrez des problèmes, veuillez ouvrir un problème sur le dépôt!

@nathanhleung , ce package semble installer toutes vos dépendances entre les dépendances homologues. Ce n'est pas tout à fait l'objet de ce billet. Ceci concerne l'installation des dépendances homologues de votre propre paquet.

Je l'ai corrigé avec un package pour le faire https://www.npmjs.com/package/@team-griffin/install -self-peers

@nathanhleung tu

Hmm ... Si on a besoin de dépendances pour le développement / test, ne devrait-on pas les mettre sous devDependencies ? Ne pas essayer de larguer une bombe ou quoi que ce soit ...

@nikolakanacki Voyez totalement d'où vous venez, je pense que la bizarrerie est que ce serait à la fois une dépendance de pair et une dépendance de développement, car vous ne devriez jamais forcer vos consommateurs à installer vos dépendances de développement. Je vote pour faciliter l'installation de pairs!

@nikolakanacki Si vous

Cas d'utilisation eslint-find-rules

Le package recherche les règles disponibles dans ESLint qui ne sont pas configurées dans votre configuration.
Pour que cela ait un sens pour un utilisateur, il doit vérifier le package ESLint qu'il a installé, et non une version spécifique de votre package (ou latest ).
Donc, c'est une dépendance peer .

Maintenant, si vous voulez contribuer au projet, vous voulez avoir ESLint installé dans node_modules afin que vous puissiez tester votre code, sans faire de npm-link avec un projet factice qui installe ESLint.

Lorsque l'utilisateur exécute yarn , le système ne doit pas installer de peer deps et avertir qu'ils sont manquants (cela fonctionne).

Donc ... un drapeau qui oblige le fil à installer des peer deps s'ils ne sont pas déjà installés résoudrait gentiment ce problème.

Point intéressant

  • yarn add <package> --peer installe dans node_modules et l'ajoute à package.json
  • yarn add <other_package> après cela supprime le package installé de node_modules

Je suis actuellement le modèle @nikolakanacki et cela semble fonctionner. Je suis d'accord que cela peut être déroutant et je préférerais un yarn install --peer pour installer dependencies , devDependencies et peerDependencies mais cela fonctionne tout aussi bien pour moi.

Si je comprends bien @gaastonsr , vous ne cherchez pas à installer peerDependencies en mode développement ( cd -ed dans le repo / package qui a peerDependencies , nouveau clone, besoin de développer sur ces peer deps) mais les ajouter au projet cible une fois que vous avez installé le paquet qui a des peer deps?

Pour clarifier: vous installez eslint-find-rules qui se plaint que vous avez besoin de eslint comme dépendance (c'est un peerDependency de eslint-find-rules ), alors maintenant vous voulez un moyen simple d'ajouter ces dépendances dans le peer lequel vous travaillez (projet actuel qui dépend de eslint-find-rules )? Quelque chose comme "Résoudre et ajouter en tant que nouvelles dépendances (modifier package.json et yarn.lock ) les dépendances homologues les mieux adaptées à mes dépendances actuelles"?

Si tel est votre point, cela pourrait être super utile, je pensais que vous faisiez référence à leur installation automatique lors du développement.

La fonctionnalité pourrait être introduite pour plus que de pure commodité, par exemple: plusieurs dépendances pourraient dépendre du même package de la cible homologue, mais nécessiter des versions différentes de celui-ci - cette fonctionnalité pourrait en tirer le meilleur parti en essayant de résoudre un seul meilleur - cible correspondante (si possible).

Quelque chose à penser définitivement.

Si tel est votre point, cela pourrait être super utile, je pensais que vous faisiez référence à leur installation automatique lors du développement.

C'est ce que je recherche. Installer peerDependencies lorsque je développe un package.

Ouais exactement @nikolakanacki! Je pense que nous avons une excellente occasion d'aider les gens à gérer leurs pairs.

@gaastonsr doit l'ajouter à devDependencies alors - c'est aussi simple que cela. Sinon, votre package est cassé pour le développement. Une fois que vous avez cloné le projet et exécuté yarn - tout devrait être installé et vous devriez pouvoir exécuter des tests, etc.

Deux questions simples et totalement indépendantes à poser avant d'installer ladite dépendance dans des cas comme celui-ci:

  1. Mon paquet dépend de ce paquet, mais je m'attends à ce que le projet cible l'inclue puisque mon paquet n'est qu'un plugin pour ce paquet: mettez-le dans peerDependencies .
  2. J'ai des tests qui dépendent de ce package mais il n'est pas listé dans mon dependencies (et ne devrait pas y figurer) pour une raison quelconque: mettez-le dans devDependencies .

En d'autres termes: tous les paquets qui devraient être présents pendant le développement et qui ne sont pas répertoriés comme une dépendance directe du paquet en cours de développement doivent résider dans devDependencies . Les doublons ne sont pas un problème - nulle part dans la documentation, il n'est indiqué que les dupes ne sont pas autorisés / encouragés dans ces cas.

@nikolakanacki Lorsque nous construisons un plugin pour un paquet, nous devrions dépendre de la version du paquet installé par l'utilisateur, si nous l'ajoutons en tant que devDependency , nous installerons inévitablement une version différente et elle sera utilisée à la place de la version de l'utilisateur.

Sauf si nous avons défini la dépendance comme * , mais alors Yarn devrait être en quelque sorte déterministe et préférer le paquet installé par l'utilisateur plutôt que le nôtre.

Actuellement, ce n'est pas le cas:

@alexilyaev Je pense que @nikolakanacki signifie l'installer à la fois en tant que peerDependency et devDependency.

Cela pose le problème dont nous avons besoin pour garder les deux synchronisés. Pour moi, cela fonctionne bien pour le moment, mais je ne pense pas que ce soit idéal.

@alexilyaev lorsque vous déclarez un peerDependency vous déclarez également sa version. À moins que le projet cible n'ait installé la version de cette dépendance de pair qui satisfait également la version que vous avez définie - yarn / npm rapportera une erreur (dépendance de pair manquante, quelque chose comme ça).

Non moins devDependency n'a rien à voir avec cela, c'est celui qui s'installe lors de l'exécution de yarn ou npm install à l'intérieur du paquet source (celui déclarant une dépendance de pair, par exemple : un plugin), et il n'est même pas consulté lorsque le package est utilisé par un package / projet tiers (un pair).

Le fait est: je ne vois pas en quoi tout cela est pertinent?

Je peux voir la douleur de les garder synchronisés, mais vous pouvez facilement écrire un script bash / javascript / <whatever> qui vérifierait cela comme une étape de post-installation dans le package.json .

Le point que j'essaie de faire valoir est que nous ne devons en aucun cas briser le sentiment devDependencies , ou pire encore introduire "l'exécution de yarn ou npm install n'installe pas nécessairement tous les dépendances requises de ce concept de package.

D'un autre côté, yarn introduit une politique encore plus stricte à ce sujet, elle efface les paquets non définis autrement comme dependencies ou devDependencies afin de ne pas courir en problèmes plus tard.

@nikolakanacki Disons que mon plugin accepte ^7.0.0 et que le dernier du pair est 7.9.0 et l'utilisateur défini dans leur package.json 7.4.0 .
si j'aurai également ^7.0.0 dans devDependencies , Yarn n'installerait-il pas (pour l'utilisateur) à la fois 7.9.0 et 7.4.0 ?

Si c'est le cas, mon plugin pourrait utiliser par erreur le 7.9.0 installé au lieu de 7.4.0 .

@alexilyaev Votre paquet utilisera toujours, comme tout autre paquet dans tous les autres cas, la version disponible la plus élevée qui satisfait la "plage semver" définie dans votre paquet pour ce dep d'homologue.

Je serais plus précis, mais je ne comprends pas très bien le cas que vous avez présenté, pourriez-vous clarifier?

~ Il vous avertira que vous avez une incompatibilité peerDependency , votre plugin attend ^7.0.0 et vous avez la version 7.4.0 . ~ Mise à jour: ^7.0.0 satisfait 7.4.0 .

Yarn n'installerait-il pas (pour l'utilisateur) à la fois 7.9.0 et 7.4.0?

Yarn n'installe pas peerDependencies pour vous et n'installe pas le devDependencies de votre plugin uniquement les dépendances dans dependencies .

@gaastonsr vous avez tout à fait raison sauf que ^7.0.0 est satisfait par 7.4.0 .

Les dépendances homologues ne sont jamais installées, les dépendances de développement ne sont pas installées par défaut si le package n'est pas le package principal. L '"utilisateur final" doit définir les dépendances homologues qu'il souhaite satisfaire en les ajoutant aux "dépendances" régulières du projet, avec la plage. Il peut satisfaire ou non la "plage semver" dont vous avez besoin dans votre plugin, et l'utilisateur en sera informé.

Plages de Semver expliquées par npm: https://docs.npmjs.com/misc/semver
En cas de doute, vérifiez toujours: http://jubianchi.github.io/semver-check/

@nikolakanacki pour pouvoir installer facilement des packages avec des dépendances entre pairs serait génial!

@nikolakanacki Ok, donc en effet, lorsque l'utilisateur final installe le package, devDependencies ne s'installe pas, donc un auteur de package doit également ajouter peerDependencies à devDependencies .

Donc, cela résout le problème du développement local.

Mais, il semble que beaucoup de projets n'ont pas ajouté la dépendance homologue en tant que dépendance de développement.
Je suppose donc que nous devrions commencer à faire passer le mot et à intégrer les projets.
Cela mènera inévitablement à de longues discussions sur les raisons pour lesquelles cela a fonctionné avec npm mais pas avec Yarn, et quels que soient les résultats, cela va prendre un certain temps et tous les projets ne peuvent pas faire le changement.

Donc ... je propose de toujours supporter un moyen d'installer des dépendances entre pairs, au moins pour que nous n'ayons plus à utiliser install-peerdeps .

Quel est le problème réel ici? Il ne semble pas que l'installation d'une liste de deps soit plus compliquée que d'installer une autre liste de deps. Les dépendances entre pairs existent depuis quelques années. Comment cela n'a-t-il dérangé personne?

La solution devDependencies configuration de peerDependencies nécessaires) et vous avez besoin de peerDependencies pour les tests intégrés et pour assurer l'hôte Le projet ne se termine pas avec des installations de paquets redondantes / dupliquées car les bibliothèques qu'il consomme utilisent les mêmes dependencies et _ ne _ font pas un bon usage de peerDependencies et devDependencies .

Il y a le petit mal de tête de les garder synchronisés. Mais comme @nikolakanacki l'a souligné, cela pourrait facilement être atténué par des scripts post-install .

Quelle solution?

J'ai parcouru les commentaires assez rapidement et je n'ai pas remarqué de solution simple:

Veuillez toujours installer peerDependencies en tant que dépendances régulières, si c'est dans le package de niveau supérieur

Il s'adapte parfaitement aux cas de développement / test et n'affecte pas l'installation du package en tant que dépendance. Similaire à la logique que nous avons pour yarn.lock. Il n'y a pas besoin de "développement" supplémentaire ou quel que soit le mode.

En fait, en raison d'autres bogues de fils liés à peerDependencies, il semble exactement comment il se comporte dans certains cas.

Tout à fait d'accord, si vous exécutez 'yarn install' dans un dépôt, il devrait installer toutes les dépendances homologues qui ne sont pas déjà répertoriées dans deps. Je ne vois pas vraiment en quoi c'est différent des dépendances de développement à cet égard - si vous développez sur ce module, vous avez _ besoin_ que ces modules soient installés

Je termine cela car je ne peux pas avoir une idée claire de la nature du problème et de la solution proposée s'il y en a.

N'hésitez pas à rouvrir avec une clarification ou à déposer un nouveau bug.

@BYK êtes-vous vraiment sûr de faire la bonne chose à résoudre les problèmes avec 55 pouces vers le haut et 34 commentaires simplement parce que ce n'est pas clair pour vous?

Je pense que c'est assez simple: assurez-vous que peerDependencies est installé lorsqu'il est défini dans le package de niveau supérieur .
Ou disons une autre façon: traiter peerDependencies comme des dépendances régulières lorsqu'elles sont définies dans le package actuel

L'ajout de dépendances homologues également en tant que dépendances de développement, comme proposé plus haut dans ce fil, interrompra le type de flux: https://github.com/flowtype/flow-typed/issues/379

@andvgal J'essaye juste de ranger les problèmes et toutes les discussions d'il y a des mois étaient accablantes et difficiles à résumer.

Je pense que c'est assez simple: assurez-vous que peerDependencies est installé lorsqu'il est défini dans le package de niveau supérieur.
Ou disons une autre manière: traiter peerDependencies comme des dépendances régulières lorsqu'elles sont définies dans le package actuel

C'était un excellent résumé merci. Rouvrir le problème, mais nous devons réfléchir très attentivement aux implications de l'installation de peerDependencies par défaut si nous décidons de suivre cette voie.

Ou - au moins - fournir un moyen d'installer séparément les dépendances homologues sans toucher au fichier package.json. Lorsque vous utilisez add pour installer une dépendance homologue, l'entrée dans le fichier JSON est modifiée. Si vous avez configuré votre expression semver d'une manière différente de celle que yarn écrit par défaut, elle est modifiée.

Je pense que l'idée d'ajouter un commutateur --peer à installer est bonne, mais j'aime en fait pouvoir les installer un par un, car je relie souvent certains de ces modules, et je vais et vient entre un lien et en fait avoir le module installé. Avec npm, je peux juste lancer 'npm i». Dans Yarn, je ne vois pas d'équivalent. Plus précisément, je souhaite pouvoir installer un fichier, en utilisant les spécifications de package.json, sans modifier le fichier package.json.

@jimsugg , j'utilise yarn add <package...> -p , pour installer manuellement les dépendances homologues déjà répertoriées dans package.json, ce qui est définitivement un anti-pattern. Il semble que les dépendances homologues devraient être automatiquement installées dans les environnements de développement (s'il s'agit en fait d'une dépendance homologue, alors il devrait au moins y avoir des tests nécessitant le package).

Je cherchais la même chose et suis venu avec ce one-liner Bash pour installer tous les peer deps listés (nécessite que vous ayez installé jq): yarn add $(jq -r '.peerDependencies|keys|join(" ")' package.json) .

J'espère que ça aidera quelqu'un d'autre.

@EdwardDrapkin Merci pour cette idée légendaire! Je l'ai étendu et j'ai fini par ajouter un script npm pour ce faire:

"install:peers": "yarn add -P $(jq -r '.peerDependencies | to_entries | map(\"\\(.key)@\\(.value | tostring)\") | join(\" \")' package.json)",

Maintient simplement la spécification de version à partir de peerDependencies ;) Seul hic ici après, c'est si vous ne voulez pas utiliser la balise latest , mais plutôt une autre sur laquelle vous travaillez comme next ou quelque chose.

@shousper voici un moyen sans la dépendance jq :

node -e "const peers = Object.entries(require('./package.json').peerDependencies || {}).map(d => d.join('@')).join(' '); if (peers.length) process.stdout.write('yarn add -P --no-lockfile ' + String(peers));" | sh

Existe-t-il un scénario dans lequel vous ne voudriez pas installer une dépendance homologue du package Foo lorsque vous travaillez directement sur Foo ? Je ne peux pas penser à un seul. Si Bar est requis pour utiliser Foo , vous en avez besoin lorsque vous travaillez sur Foo , et comme il s'agit d'une dépendance homologue, ce ne peut pas être une dépendance régulière. Il ne devrait alors être installé que lorsque vous travaillez directement sur le paquet, ce que font les dépendances de développement.

Pour cette raison, je pense qu'il est logique pour yarn de traiter peerDependencies de la même manière que devDependencies, mais de faire ensuite ce qu'ils font maintenant, à savoir générer des avertissements. Je fais généralement de chaque dépendance de pair une dépendance de développement, donc cela éviterait des doublons.

Y a-t-il une raison pour laquelle cela poserait problème? Ce serait probablement un changement radical, il faudrait donc attendre la version 2.0, mais à part cela, il semble que cela devrait aller.

Un problème peut être que vous voulez une version plus spécifique installée pour le développement que votre exigence d'homologue. Dans ce cas, je dirais que vous devriez pouvoir remplacer la version homologue pour les installations locales en la dupliquant dans devDependencies. Par exemple

peerDepdency: react@^16.0.0
devDependency: react@~16.1.0

Limiterait l'installation locale de react à ~ 16.1.0, mais autoriserait toute version v16 en tant que dépendance homologue. Je ne sais pas vraiment où quelque chose comme ça serait nécessaire, mais cela ne semble pas invalide.

Je suis d'accord @bdwain , je comprends sémantiquement quelle est la différence entre une dépendance peer et dev, mais en pratique, ils sont installés exactement de la même manière; si vous êtes en train de développer le module, vous devez installer les dépendances de développement et d'homologue, et si vous utilisez le module, vous n'installez que ses dépendances réelles répertoriées. Si tel est le cas, je ne vois pas de très bonne raison pour que les dépendances dev et peer ne se comportent pas différemment dans la commande install

@bdwain @kyleholzinger Je ne suis pas d'accord, car peerDependencies sont strictement destinés à informer le besoin d'une dépendance, pas à indiquer l'action réelle d'installation de la dépendance.

Cela garantit que le problème des versions de dépendance transitoires qui existent également dans le package racine / de niveau supérieur ne sont pas utilisés en silence (et de manière incorrecte). Considérez babel-core comme exemple.

Le support qui manque ici dans le contexte du fil est la capacité de se définir à la fois comme un pair et un dev dep, comme décrit ici .

Cela dit, pour rester en ligne avec la spécification d'installation par défaut pour les pairs et pour fournir une meilleure expérience de développement ... peut-être que yarn pourrait introduire une option --include-peers pour la commande d'installation?

@hulkish Bien que je sois d'accord avec le sentiment, quand serait un exemple où vous voudriez déclarer quelque chose en tant que dépendance d'homologue, mais _pas_ en tant que dépendance de développement?

Si je comprends bien l'utilisation, en particulier avec yarn, la liste des dépendances homologues est toujours un sous-ensemble des dépendances dev. Si tel est le cas, je pense que cela devrait être officiellement reconnu et que vous ne devriez pas avoir besoin de déclarer les dépendances homologues en tant que dépendances dev.

La seule raison pour laquelle j'en parle, c'est que je pense que l'ajout d'une commande / option qui ajouterait quelque chose en tant que dépendance de développement et de pair donne l'impression que cela augmenterait la complexité du fil en général, et j'ai l'impression qu'il y a une solution quelque part ici, c'est bien et simple 😄

@kyleholzinger

@hulkish Bien que je sois d'accord avec le sentiment, quand seriez-vous un exemple où vous voudriez déclarer quelque chose en tant que dépendance de pair, mais pas en tant que dépendance de développement?

Lorsque vous n'en avez pas besoin pour exécuter vos tests unitaires ou .build. D'après mon expérience, c'est en fait le seul besoin de les ajouter aux deux endroits, pour commencer.

Je pense que la solution ici est pour le fil d'introduire une option qui permet l'installation automatique de pairs. Gardez en nature que le principal avantage de l'utilisation de peerDependencies est de mieux comprendre le moment où des dépendances transitoires incompatibles sont utilisées. La clé ici est de ne pas briser le comportement par défaut des peer deps lors de l'installation.

Je pense que @hulkish parlait d'un scénario dans lequel vous comptez sur une dépendance d'une dépendance pour extraire l'une de vos dépendances homologues. Cependant, je ne pense pas que cela causerait des problèmes car la dépendance transitive devrait toujours correspondre à la plage spécifiée par la dépendance homologue, qui doit de toute façon être une large plage. Si la dépendance transitive était plus spécifique que la dépendance homologue, cette plage prévaudrait et toutes les exigences seraient toujours satisfaites.

@hulkish

Lorsque vous n'en avez pas besoin pour exécuter vos tests unitaires ou .build

Entièrement compris! Bien que cela soulève la question: si quelque chose est une dépendance d'homologue, mais que vous n'en avez pas besoin pour que votre test unitaire ou votre build s'exécute, alors pourquoi l'avez-vous en tant que dépendance d'homologue?


Gardez en nature que le principal avantage de l'utilisation de peerDependencies est de mieux comprendre le moment où des dépendances transitoires incompatibles sont utilisées

Je suis tout à fait d'accord avec cela, je pense que les dépendances entre pairs sont incroyables en ce moment de la part du consommateur du module qui déclare la dépendance à une bibliothèque avec des dépendances entre pairs, mon principal reproche / problème est lors du développement sur des modules qui ont des dépendances entre pairs. Désolé s'il y avait une confusion!

Ma principale demande / suggestion / espoir-de-faire-approuver-pour-travailler serait que lorsque vous yarn install (pas en production) dans un module qui a des dépendances de pairs dans son propre package.json que ses deux dépendances de développement _ ainsi que_ ses dépendances homologues sont installées. C'est la principale différence, pour le moment, seules les dépendances dev sont installées, vous devez donc déclarer deps à la fois comme dépendances dev et comme dépendances homologues.


@bdwain @hulkish

Je pense que @hulkish parlait d'un scénario dans lequel vous comptez sur une dépendance d'une dépendance pour extraire l'une de vos dépendances homologues

Je parle spécifiquement du moment où vous faites yarn install lors du développement d'un module avec des dépendances homologues, pas lorsque vous ajoutez un module avec des dépendances homologues à un autre projet

@bdwain pas exactement, c'est certainement une chose glissante à décrire. J'essaierai d'utiliser un exemple:

Cas d'utilisation avec problème

Disons que c'est votre package de premier niveau:

  "dependencies": {
    "foo": "^4.0.0",
    "react": "^15.0.0"
  }

puis, votre foo / package.json:

  "dependencies": {
    "react": "^16.0.0"
  }

Selon cet arbre de dépendances, lorsque vous exécutez l'installation yarn / npm, votre répertoire node_modules ressemblera à ceci:

node_modules/
  react/ <-- @^15.0.0
  foo/node_modules/react/ <-- @^16.0.0

À ce stade, à moins que vous ne décidiez (pour une raison quelconque) d'inspecter volontairement votre structure de répertoires imbriqués node_modules - vous ne saurez jamais qu'il y a un problème. Ce n'est pas la faute du gestionnaire de paquets - il a terminé son travail avec précision.

Ainsi, peerDependencies est destiné à résoudre ce cas d'utilisation en les traitant davantage comme un contrôle de validation plutôt que comme une instruction d'installation.

Cas d'utilisation avec la solution peerDependencies

  "dependencies": {
    "foo": "^4.0.0",
    "react": "^15.0.0"
  }

puis, votre foo / package.json:

  "peetDependencies": {
    "react": "^16.0.0"
  }

Tout d'abord, soyons clairs à ce stade, les deux cas d'utilisation ont le même problème de versions de réaction incompatibles entre elles.

La différence dans ce cas d'utilisation est; Au lieu de ce problème existant en silence. Lorsque vous exécutez npm / yarn install, le gestionnaire de packages a le devoir de signaler l'incompatibilité comme une erreur ou un avertissement.

J'espère que cela explique mieux.

@kyleholzinger

Je parle spécifiquement du moment où vous effectuez l'installation de fil lors du développement d'un module avec des dépendances homologues, pas lorsque vous ajoutez un module avec des dépendances homologues à un autre projet

Je comprends. Je pense que le comportement par défaut des peer deps devrait rester tel quel. Mais, je pense qu'une solution simple est de permettre à cela d'être configurable via cli et / ou env vars et / ou .yarnrc . Quelque chose comme --install-peers-as-dev

@hulkish

Mais, je pense qu'une solution simple est de permettre à cela d'être configurable via cli et / ou env vars et / ou .yarnrc. Quelque chose comme --install-peers-as-dev

Putain, oui! Je pense personnellement qu'ils ne devraient pas être à la fois dans des dépendances de développement et des dépendances entre pairs, mais cela pourrait être une discussion séparée. Je pense que l'ajout de cette option serait un compromis solide et un excellent moyen de résoudre le problème en attendant - je vais le vérifier et essayer de lancer quelque chose ensemble :)

@kyleholzinger c'est un bon endroit pour commencer https://github.com/yarnpkg/yarn/blob/master/src/cli/commands/install.js#L58

De plus, j'encourage dans votre communication que lors de la transmission de peerDependencies à installer en tant que dev - vous voulez vous assurer que tous les avertissements ou erreurs de compatibilité sont toujours signalés.

@hulkish Je comprends ce que sont les dépendances entre pairs. Mon point était qu'en pratique, vous en avez toujours besoin installés à des fins de développement, donc ils devraient être traités comme devDependencies en plus de leur rôle d'avertissement lorsque les versions ne correspondent pas.

Si un paquet Foo a une dépendance d'homologue sur Bar, le seul scénario où vous ne voudriez pas que Bar soit installé lorsque vous travaillez directement sur Foo serait si votre build et vos tests automatisés n'avaient pas besoin de Bar. Mais si tel était le cas, cela signifierait simplement que votre build / tests n'exerçaient pas la fonctionnalité qui nécessitait la dépendance des pairs sur Bar en premier lieu, ce qui ne devrait pas être le cas courant.

Je ne pense pas vraiment qu'une option permettant d'activer l'installation automatique des dépendances entre pairs soit la bonne chose à faire car elle serait nécessaire beaucoup plus souvent qu'autrement (à moins que vous n'ayez également spécifié des pairs comme dépendances de développement, ce qui va à l'encontre du point). Si une option est nécessaire plus souvent qu'autrement, elle devrait être la valeur par défaut et il devrait y avoir une option pour la désactiver à la place. yarn install devrait fonctionner sans options pour les cas les plus courants, et le besoin de dépendances homologues pour être traitées comme des dépendances de développement est le cas le plus courant. Ajouter une étape supplémentaire pour l'utilisateur moyen est juste une expérience pire.

Et les ajouter automatiquement à la fois au développement et au pair pose toujours le problème de la duplication de la dépendance à deux endroits, ce que l'OMI est un problème et ne devrait pas être nécessaire.

Dans tous les cas, ces avertissements / erreurs doivent être signalés.

Comment est-il possible que nous n'ayons pas encore cette fonctionnalité? Je suis nouveau dans la création de packages npm, mais il semble que cela fasse partie du flux de travail principal du développement de packages npm.

Même @biels! En fait, j'ai totalement oublié que j'avais dit que j'allais travailler dessus, donc je n'ai pas encore commencé, j'essaierai de travailler dessus quand je le pourrai afin que nous puissions au moins demander aux gens de mettre cette option dans un .yarnrc et ne pas avoir à s'en soucier tout le temps

Je pense que cette fonctionnalité est extrêmement importante.

Je peux penser à de nombreux cas d'utilisation, en particulier en ce qui concerne les auteurs de bibliothèques.

Disons que je veux développer une bibliothèque de composants qui a react et react-dom comme peerDependencies (je ne veux pas qu'ils soient éventuellement regroupés par celui qui l'utilise, cela dupliquerait ces deux bibliothèques et pourrait causer des problèmes, que j'ai déjà rencontrés).

Je veux tester ma bibliothèque de composants avec ces peerDependencies installés, donc j'aimerais exécuter yarn --include-peerDeps (ou quelque chose comme ça) sur CI et sur ma machine, mais quand quelqu'un exécute yarn sur leur propre paquet Je veux qu'ils utilisent leurs propres dépendances react et react-dom pour exécuter leurs tests (peu importe comment ils le font).

Je pense aussi que puisque nous avons des modules qui font exactement cela et que nous avons beaucoup de téléchargements, cela justifie déjà de rendre cette fonctionnalité native. (L'ancienne devise «créer quelque chose que les gens veulent» s'applique ici à l'OMI)

Je ne vois pas en quoi cela pourrait être une mauvaise pratique car il faudrait explicitement basculer entre --include-peerDeps .

Je suis heureux de discuter et d'aider à la mise en œuvre si nécessaire.

@lucasfcosta ne pouvait pas être plus d'accord! Je n'ai pas beaucoup de temps pour travailler dessus ces jours-ci, j'ai donc essayé de fouiller quand je le pouvais, mais je n'arrivais pas à obtenir l'option véridique à partir de l'option de ligne de commande. J'adorerais un coup de main :)

@lucasfcosta voici ma mauvaise implémentation de l'endroit où je pensais que l'option pourrait vivre, je n'en ai aucune idée cependant. Essayait de suivre le modèle de quelques autres options de ligne de commande, mais ne semblait pas fonctionner.

J'adopte actuellement l'approche de duplication (devDependencies et peerDependencies) mais j'aimerais beaucoup cette fonctionnalité afin que je puisse arrêter de le faire.

J'ai besoin de ça aussi. en attendant, j'ai fait une petite tâche de nœud

const pkg = require('./package.json');
const entries = Object.entries(pkg.peerDependencies);
const shell = require('shelljs');

let deps = ['yarn add'];
for ([dep, version] of entries) {
    deps[deps.length] = `${dep}@${version}`;
}

deps.push('--peer');
const cmd = deps.join(' ');
console.log('Installing peer deps!\n -----', cmd);
const result = shell.exec(cmd);

if (result.code !== 0) {
    shell.echo('Error: installing peer dependencies');
    shell.exit(1);
}

Cool! Maintenant, nous pouvons simplement le coller dans du fil et ajouter un drapeau ou autre.

Le jeu.4 oct.2018, 17:29 Pasquale Mangialavori [email protected]
a écrit:

J'ai besoin de ça aussi. en attendant, j'ai fait une petite tâche de nœud

`const pkg = require ('./ package.json');
entrées const = Object.entries (pkg.peerDependencies);
const shell = require ('shelljs');

let deps = ['yarn add'];
for ([dep, version] des entrées) {
deps [deps.length] = $ {dep} @ $ {version};
}

deps.push ('- pair');
const cmd = deps.join ('');
console.log ('Installation de peer deps! n -----', cmd);
résultat const = shell.exec (cmd);

if (result.code! == 0) {
shell.echo ('Erreur: installation des dépendances homologues');
shell.exit (1);
} `

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/yarnpkg/yarn/issues/1503#issuecomment-427063046 , ou muet
le fil
https://github.com/notifications/unsubscribe-auth/AE64MGxna2iQ-BFNiC52mIVro8sydPu1ks5uhilsgaJpZM4KiMuo
.

Je prends également l'approche de la duplication comme l' a dit

Btw, est-ce que quelqu'un a une meilleure solution pour que nous n'ayons pas besoin d'ajouter un paquet deux fois (devDependencies et peerDependencies)?

Bonjour du futur. C'est toujours un problème pour les développeurs de packages / lib. Les doublons ne devraient pas être la solution.

J'aimerais vraiment voir cette fonctionnalité ajoutée. Sans ajouter react pour mon forfait devDependencies , je suis incapable d'exécuter des tests sur mon code.

Un drapeau pour installer les packages dans l'objet peerDependencies local serait bien mais je ne vois pas non plus d'inconvénient à faire de l'installation _only_ locale peerDependencies le comportement par défaut. Et sémantiquement, cela a du sens, les dépendances entre pairs doivent être là pour que le package fonctionne partout ailleurs, pourquoi serait-il différent localement?

Mon opinion sur l'utilisation d'un drapeau serait la suivante en raison de son alignement avec le
yarn add --peer commande.

yarn --peer
# and
yarn install --peer

À tout le moins, le drapeau devrait être introduit.

Je me demande si l'utilisation d'une application test distincte est une bonne solution ici? Vous pouvez ensuite ajouter tous vos peerDependencies tant que dependencies de l'application test . Cela semble faire ce qui suit:

  • garde peerDependencies sur devDependencies dans votre bibliothèque
  • vous allez tester e2e votre bibliothèque, d'une certaine manière ... en vous assurant que votre dist est construit correctement, vous exportez tous vos composants correctement et ce genre de chose
  • évite l'erreur occasionnelle Invalid hook call lorsque vous oubliez d'effacer node_modules de votre package lorsque vous utilisez des dépendances locales, comme "my-package": "file:/path/to/my-package"

Si plus d'informations seraient utiles pour les gens, j'ai créé un dépôt de démonstration dans le but de modéliser cette approche et de documenter le problème:
https://github.com/jamstooks/package-peer-dependencies

Pour l'instant, vous devriez pouvoir exécuter npx install-peerdeps <package> et la CLI vous demande alors si vous souhaitez utiliser Yarn pour l'installation, si vous avez un verrou de fil, etc. dans le dossier. Au moins cela a fonctionné pour moi tout à l'heure.

Plus de discussion d'Arcanis ("échouer l'installation sur les peer deps manquants") et Isaac ("installer les peer deps automatiquement") ici dans ce RFC NPM:

https://github.com/npm/rfcs/pull/43

J'ai un problème connexe, je pense.
Pour la repro minimale, j'ai cette liste de dépendances:

  "dependencies": {
    "prismic-reactjs": "^1.2.0"
  },
  "peerDependencies": {
    "react": "^16.12.0"
  },
  "devDependencies": {
    "react": "^16.12.0",
    "redux": "^4.0.5"
  }

Explication: mon package repose sur la présence de react au moment de l'exécution et en a également besoin pour les tests. redux est ici à des fins de démonstration, voir ci-dessous.

Maintenant, prismic-reactjs s'appuie également sur react comme dépendance de ses pairs.
Que se passe-t-il après l'appel de yarn --production ?

React est à la fois _installed_ et _hoisted_
Je m'attendrais à ce qu'aucun des deux ne se produise.

À des fins de démonstration, redux est ajouté ici, ce qui n'est pas installé, ce qui (je pense) prouve que la dépendance transitoire des pairs est la cause du problème.

Repro repo: https://github.com/emirotin/yarn-react-repro . Exécutez test.sh pour la vérification rapide.

npm a cette fonctionnalité maintenant avec la v7 ... une raison de ne pas l'ajouter au fil?

@sajadghawami pour autant que je sache, @arcanis a de très grandes réserves à faire ceci:

https://github.com/npm/rfcs/pull/43#issuecomment -520584797

Cette page vous a été utile?
0 / 5 - 0 notes