Yarn: Ajouter un package sans enregistrer dans package.json

Non, cette fonctionnalité a été laissée de côté intentionnellement. Il est considéré dangereux d'installer un package sans être reflété dans le package.json. Pourquoi voulez-vous qu'une telle chose existe?

De l' annonce Facebook

Nous avons supprimé le comportement de «dépendance invisible» de npm installet divisez la commande. Lancer yarn add <name> équivaut à exécuter npm install --save <name> .

J'utilisais cette fonctionnalité assez souvent pour tester des choses. Surtout quand je travaille avec une bibliothèque que je maintiens et que j'ai besoin d'installer une version locale (qui crée un file: dep) juste pour tester mes modifications avant de créer une version.

Bien que je convienne que l'implémentation de npm pour le faire par défaut était un mauvais choix, je pense que c'est quelque chose qui peut être utile lorsqu'il est utilisé explicitement.

Oui, je pense que le laisser faire avec un drapeau explicite serait bien d'avoir, actuellement pour celui-ci, on peut toujours utiliser npm i =) mais juste pour se débarrasser du besoin de npm.

Nous ne soutenons pas explicitement cela car il s'agit d'un changement impératif de node_module qui serait effacé avec les yarn install s suivants puisque nous considérons package.json et yarn.lock comme étant la source de la vérité.

Nous avons une dépendance qui ne peut pas être installée facilement sur Windows (libxslt) donc:

• Pour Windows: les développeurs le décompressent dans leurs node_modues
• Pour linux: les développeurs l'installent sans sauvegarde (si c'est dans package.json, les développeurs utilisant Windows ne peuvent pas effectuer d'installation car la compilation échouera)

Y a-t-il un moyen propre de le faire en utilisant du fil (ou une meilleure façon d'obtenir ce résultat)?

(Je suis d'accord avec vous que les packages doivent être reflétés dans package.json, mais ici je ne trouve pas de solution propre)

@GuillaumeLeclerc Qu'en est-il de yarn add -D xxx et supprimez vous-même l'entrée du package.json?

Il sera supprimé la prochaine fois qu'un autre package sera ajouté? N'est-ce pas?

@GuillaumeLeclerc Malheureusement, oui.

@GuillaumeLeclerc Vous voudrez peut-être nettoyer votre commentaire ...

Veuillez ajouter un argument comme yarn add --no-save afin que je puisse installer un module sans modifier mon package.json ou yarn.lock. J'ai souvent besoin de tester des modules avant de m'y engager.

Je ne peux pas utiliser le npm install normal car j'obtiens "Taille maximale de la pile d'appels dépassée". Le fil est donc le seul moyen viable d'installer.

Veuillez ne pas me faire annuler les modifications apportées à package.json yarn.lock!

Pour moi, cela me pique parce que j'essaye d'installer un peerDep. Yarn n'a aucun moyen d'installer des peer deps pendant install donc je dois le faire manuellement. Je ne peux pas yarn add <package> sans l'avoir ajouté au package.json / yarn.lock. Je suis coincé.

@viveleroi cela semble totalement correct. Pourquoi voudriez-vous installer la dépendance homologue sans l'ajouter à votre package.json ?

@hpurmann Parce qu'il duplique mon peerDependencies dans dependencies (ou devDependencies si j'utilise --dev ). Si c'est ce qui est prévu, ce n'est certainement pas intuitif.

@hpurmann Je veux rendre public un composant react, donc react devrait être un peerDep. Cependant, je dois installer react dans le projet pour le développer.

ajoutez simplement --no-save => c'est si important
je dois sauter une dépendance facultative particulière pour un paquet spécifique. je ne peux pas faire ça avec votre laine. peut-être avec l'option --no-save, je peux le travailler autour

Parce que yarn link local-pkg n'installe pas les dépendances de local-pkg dans l'application hôte, je voudrais les installer directement mais ne pas les enregistrer dans l'application package.json car elles seront apportées par local-pkg une fois qu'il sera publié .

Je ne comprends pas pourquoi les propriétaires sont si avisés à ce sujet. Si vous n'en voyez pas d'utilisation, cela ne veut pas dire qu'il n'y en a pas. Je crois que si les gens le demandent, cela signifie qu'ils en ont besoin, et ils ne sont pas forcément stupides.
L'ajout d'une option optionnelle --no-save résoudrait le problème de certaines personnes et n'apporterait aucun inconvénient.

J'essaie d'utiliser Yarn pour un projet NodeJS exécuté sur AWS Lambda. Je suis un peu surpris de savoir pourquoi cette fonctionnalité n'est pas prise en charge. Mon cas d'utilisation est que j'ai besoin d'installer aws-sdk sur mon environnement de développement local, mais je ne veux pas qu'il soit enregistré dans package.json car AWS Lambda l'a déjà installé sur son environnement. Inclure aws-sdk signifie que notre paquet final serait gonflé.

le lien de fil et l'ajout de fil ne peuvent pas cohabiter. yarn add dépend de package.json tandis que yarn link relie simplement les packages locaux à un autre emplacement.

Supposons que vous développiez un package X qui dépend de Y, vous êtes à la fois le développeur de X et Y, donc vous gardez X et Y localement et liez Y dans le répertoire de X. Lorsque vous ajoutez du fil à X, cela efface le lien vers Y.

Comment contourner ce problème?

~ Dans de tels cas, vous pouvez simplement utiliser les commandes npm pour installer sans créer une empreinte sur le package json ou yarn.lock: ~

~ npm install [packages ...] --no-save --no-package-lock ~

comme @heikomat indiqué ci-dessous, puisque npm5 utilise l'auto-élagage après l'installation (voir https://github.com/npm/npm/issues/16853 + https://github.com/npm/npm/pull/18921) c'est pas une option et pourrait casser complètement votre dossier node_modules.

ok alors maintenant je ne peux pas vivre sans npm alors

J'utilisais npm install dans l'un de mes scripts qui installe les dépendances des sous-modules locaux sur les principaux node_modules. Cela fonctionne bien avec npm4, mais est complètement cassé avec npm5, car npm5 décide simplement de détruire certains paquets pendant l'installation -.- (voir https://github.com/npm/npm/pull/18921)

Pour cette raison, j'essayais de remplacer le npm install dans mon script par du fil, mais je ne peux pas vraiment le faire, si le fil touche toujours le package.jsons des sous-modules locaux lors de l'installation, du moins pas sans mon script devient discret et "nettoie" après le fil

Vous avez déjà l'option --no-lockfile , donc cela rend le dossier node_modules hors de pensée,
mais les développeurs doivent toujours avoir des solutions de contournement pour garder package.json immuable.

Je vous remercie.

J'aime le fait que chaque fois que quelqu'un explique son cas d'utilisation particulier pour installer un module sans l'enregistrer, les responsables reviennent et récitent leurs shibboleth. Il doit être facile de se sentir confiant dans votre obstination si vous pouvez formuler cette même demande de nombreuses personnes différentes comme venant de ceux qui souffrent d'un échec moral. En guise de compromis, nous pourrions peut-être nommer le commutateur --i-am-a-heritic-and-a-bad-programmer ?

Triste de voir que le seul défaut clé que yarn préserve de npm est son antagonisme envers toute personne extérieure à leur organisation.

Et dans mon cas, je voulais l'utiliser comme solution de contournement pour le problème # 4297 :)
Limiter artificiellement les développeurs à faire des choses peut rendre votre produit inutilisable dans certaines situations.

Attends tu te moques de moi? C'est une parodie. Veuillez cesser de dicter le fonctionnement de chaque flux de travail de développeur. C'est exactement pourquoi NPM ne nous convenait pas et nous sommes passés à Yarn. Cette idéologie selon laquelle "package.json et yarn.lock devraient être source de vérité" est absurde. Les packages doivent pouvoir être installés sans modifier le code source. Aussi simple que cela.

Allez, les mainteneurs. Il est évident que la communauté en a vraiment besoin. Veuillez arrêter de mettre fin à une conversation intelligente avec une philosophie non filtrée et mal placée.

Maintenant, je trouve que yarn casse mes tests parce que j'ai des modules où je dois tester require et que pour tester, je valide un module d'exemple dans ./node_modules . Yarn supprime les modules d'exemple lorsque j'exécute yarn install . Plus de pédantisme «source de vérité», je suppose.

cas d'utilisation: l'outil que j'utilise nécessite un package. L'équipe n'utilise pas cet outil. L'équipe (à juste titre) ne veut pas que ce package soit installé.

C'est vraiment frustrant. J'utilise codelyzer pour le guide de style angulaire, mais le reste de mon équipe ne le fait pas et cela n'a aucun effet sur la fonctionnalité du code. La seule façon de le faire fonctionner maintenant est de l'ajouter à mon verrou de fil et de supposer simplement que mon verrou de fil n'a pas réellement changé ou d'utiliser npm même si mon équipe utilise du fil. Ces deux options sont horribles.

Nous sommes déjà en 2018 mais cette fonctionnalité n'a pas encore été ajoutée malgré les nombreux cas d'utilisation valides.

Juste pour donner un autre exemple pourquoi cela pourrait être utile:

Nous avons un script qui met automatiquement à jour les dépendances en installant la nouvelle version, en exécutant les tests, puis en l'enregistrant dans le package.json / *.lock et en validant ce changement OU en rétablissant s'il y avait une erreur. Il est beaucoup plus facile d'exécuter à nouveau yarn au lieu de se souvenir de l'ancienne version et explicitement adding .

De plus, il semble plus propre de ne pas muter votre point de vérité unique ( package.json ) avant d'être "absolument" sûr de pouvoir vraiment mettre à jour cette dépendance sans casser un test. Pour l'instant, vous vous retrouvez avec un package.json (même si c'est temporairement) contenant une dépendance qui rompt votre code.

Il existe de nombreux cas d'utilisation valides pour ce problème. Les mainteneurs de yarnpkg seraient-ils disposés à accepter un PR s'il en était créé un?

ping à @kittens si vous êtes toujours affilié à ce projet ...

En attendant, j'utilise le script suivant dans la section scripts de package.json :

"scripts": {
  "install-sneaky-package": "npm install -g sneaky-package && cp -r $(npm root -g)/sneaky-package ./node_modules/sneaky-package"
}

Je suppose qu'il existe une alternative au fil?

Il n'y a pas d'alternative, npm5 est en désordre comme ma vie.

Et n'oubliez pas de copier les liens symboliques dans le dossier .bin. ;)

Pour moi, chmod 444 package.json et yarn add XXXX --no-lockfile travaille au moins autour du problème pour le développement local et les tests.
L'ajout se termine par une erreur d'autorisation (attendue), mais le module ajouté est présent dans node_modules par la suite et je suis capable de tester avec des dépendances homologues installées localement mais pas persistantes dans package.json mais en tant que dépendance homologue.

J'ai parfois besoin d'une bibliothèque de débogage temporairement, comme why-is-node-running . Je sais que je veux m'en débarrasser après une seule utilisation, et une option --no-save me permettrait d'installer et d'oublier, sans courir le risque de polluer mes dépendances.

J'utilise Lerna, et je veux vraiment installer _only_ Lerna dans l'une de mes étapes CI, pour l'étape de publication, car le projet est déjà construit dans une étape précédente et les artefacts reportés. Est-ce un scénario valable?

Cela me ferait gagner quelques étapes si cette fonctionnalité était disponible.
Mon node_modules est de toute façon en .gitignore.

Au lieu de:

git clone external-package (needed for temp testing only)
yarn install
yarn link

revenir à mon dépôt d'origine
yarn link external-package

juste:
original-repo:
yarn install external-package --no-save

Dans le cadre de nos pipelines de construction, nous devons installer nsp et l'exécuter, en exportant un fichier dependency-check.xml.

Je ne vois pas pourquoi cette installation d'outil simple doit être reflétée dans la liste des packages, cela signifie simplement que je dois maintenant faire un git checkout ${BRANCH_NAME} pour annuler les modifications avant de pouvoir pousser les balises.

Je n'essaye pas de modifier la source. Je ne veux pas et ce n'est pas mon affaire, cela dépend des équipes de développement de mon organisation. Vous me rendez la vie un peu plus difficile pour une philosophie abstraite. Arrête ça.

Une idée, pourquoi ce problème a été fermé? Le commutateur --no-save été ajouté dans un PR?

Il y a des moments où je veux changer la version d'un module qui est importée d'une dépendance. Par exemple, @types/sinon introduit par une autre dépendance de développement a récemment cassé mon tsc. Je ne veux pas de @types/sinon dans mes dépendances de développement, mais je veux changer manuellement la version avec yarn add @types/[email protected] --no-save afin de pouvoir continuer à travailler. Au lieu de cela, je reviens simplement à npm. Super frustrant.

J'ai une dépendance de production uniquement (appdynamics) qui est en grande partie un hack de binaires spécifiques à la plate-forme. Il s'avère que nous n'en avons même pas besoin sur les machines de développement. L'ajout de yarn add ... --no-save nous permettrait de déployer proprement sans que le script ne mette en danger le package.json (d'autant plus que package.json, odieusement, ne peut pas avoir de commentaires expliquant le but de chaque script ou dépendance)

cc @kittens @hpurmann

Veuillez résoudre ce problème extrêmement populaire ou le verrouiller comme résolu. Il serait très apprécié d'avoir une réponse concrète en réponse à toutes les critiques soulevées ci-dessus.

Et la communauté est prête à fournir la fonctionnalité, faites-nous savoir si vous acceptez une telle demande d'extraction. Je vous remercie.

haha, toujours pas implémenté, niiiiice

Pourquoi voulez-vous qu'une telle chose existe?

C'était exactement la même chose que les gens ont dit à propos de JSX quand il est sorti pour la première fois en mélangeant les modèles et la logique. Si c'est possible et a ses cas d'utilisation, la bonne question devrait être pourquoi pas? Je veux dire que c'est un drapeau, ce n'est pas un comportement par défaut, donc vous dites explicitement au fil (aka je sais ce que je fais).

@kittens @hpurmann
J'ai plusieurs packages basés sur react et ceux-ci ont des dépendances de sous-modules les uns sur les autres. donc j'ai react et react-dom en tant que peer-dep, mais quand j'ai besoin de construire ces packages individuellement, j'ai besoin de react et react-dom.
Je suppose que ce serait un cas d'utilisation approprié pour installer des paquets localement sans les avoir ajoutés en tant que dep.
Je n'aimerais pas avoir npm pour une utilisation aussi triviale dans mon projet.
Toutes les mises à jour, en attente de quelque chose de similaire à --no-save .
Je suppose qu'il n'y a aucun mal à ajouter une fonctionnalité si la communauté le demande, en supposant que le développeur soit conscient de ses effets secondaires (perdre les packages locaux dès que vous exécutez l'installation de yarn.)
Merci

L'astuce pratique est yarn add --dev pkg && yarn remove pkg . Cela fait la même chose. Le fichier de verrouillage reste tel qu'il était avant cela, donc intact.

Cela a été mentionné par @Legends plus tôt mais mérite d'être souligné:

Une solution de contournement pour certains cas consiste à installer le package nécessaire dans un dossier séparé et yarn link le package nécessaire à l'endroit où il aurait été ajouté autrement. Ce n'est pas idéal mais peut aider.

cd /third-party
yarn add foo
cd node_modules/foo
yarn link

cd /my-project
yarn link foo

@silentorb ne vaut vraiment pas la peine, à mon humble avis. Le add + remove est exactement ce qui est fait avec le --no-save en npm. Cela ne perturbe pas les liens système et ne touche pas le fichier de verrouillage de manière incorrecte - ce qui signifie que c'est la même chose après le yarn remove .
Sans oublier que si vous voulez faire cette chose par programme, créer définitivement des répertoires, des liens, etc. n'est pas la voie à suivre.

certains cas

Par exemple? Assez bizarres, c'est sûr?

@hpurmann @kittens

Alors, quelle est la pratique recommandée pour développer un package avec des dépendances homologues?

Si j'ai par exemple React en tant que peerDependency dans mon package, dois-je également l'ajouter en tant que devDependency afin de résoudre les importations?

En regardant https://github.com/airbnb/javascript/blob/master/packages/eslint-config-airbnb/package.json, je suppose que la réponse est oui

@ 18steps consultez https://www.npmjs.com/install-peers

Il existe certaines situations pour utiliser cette fonctionnalité.

Tout comme dans le cycle de vie CI, j'ai ajouté un journaliste de couverture. Mais je ne peux pas les amener à package.json puis affecte à publier NPM .

Enregistrer ou pas enregistrer, je pense que ce choix devrait appartenir aux développeurs eux-mêmes et non à l'outil.

Très bien, essayons de regarder cela du point de vue des responsables. Je peux certainement voir les inconvénients d'une solution naïve --no-save . Nous n'avons pas eu d'explication très approfondie ici, mais je vais essayer de construire un homme d'acier. Peut-être qu'ils peuvent me corriger. Peut-être pouvons-nous trouver un compromis. @kittens @hpurmann

(Désolé, cela a duré plus longtemps que prévu.)

La gestion des dépendances pour les applications Node et Web modernes est un peu chaotique. Et pourtant, nous voulons un système qui nous offre à la fois une automatisation fiable et un certain niveau de contrôle et de prévisibilité, avec des fonctionnalités telles que la déduplication et des versions reproductibles.

Pour comprendre la complexité, nous devons savoir ce qui est installé et pourquoi, et nous avons besoin d'une source unique de vérité pour résoudre toute incohérence. Au risque de déclarer l'évidence, node_modules ne peut lui-même remplir aucun de ces rôles. Il est trop lent à parcourir, trop volumineux à transmettre, trop fin pour le contrôle de version, et il ne peut pas encoder l'aspect «pourquoi». C'est pourquoi nous avons package.json et yarn.lock .

Yarn encapsule la complexité de node_modules en nous donnant un accès restreint via une interface. Si nous promettons de ne pas interrompre l'encapsulation, nous obtenons en retour certaines garanties, comme la déduplication et les builds reproductibles. Si nous installons des choses dans node_modules sans changement correspondant dans package.json et yarn.lock , nous perdons ces garanties.

De plus, c'est un contrat tacite dont de nombreux développeurs ne sont pas explicitement conscients. Quand ils le cassent, ils ne le font pas sciemment. Ainsi, lorsque les choses tournent mal, Yarn peut être injustement blâmé. De plus, fabriquer un outil avec lequel il est difficile de se tirer une balle dans le pied n'est pas une mauvaise philosophie de conception.

Cependant , je vois plusieurs raisons de faire des compromis:

• Il semble y avoir un besoin certain ici. Regardez simplement les nombreux cas d'utilisation énumérés dans les commentaires ci-dessus, et les ratios «pouces vers le haut» / «pouces vers le bas». L'apparente obstination des mainteneurs face à une telle réponse unilatérale ne donne pas à Yarn une apparence trop belle.

• Il existe des solutions à trouver qui peuvent convenir à tout le monde. Par exemple, introduisez un nouveau fichier yarn.local.lock . Les développeurs le mettraient dans leur .gitignore , et il garderait une trace de tous les paquets installés avec l'indicateur --no-save et leurs dépendances.

  Afin de garder yarn.lock isolé de cela, la déduplication et l'aplatissement de l'arborescence de dépendances «locale» sont limités. Le fichier de verrouillage local peut s'adapter pour correspondre à une version du fichier de verrouillage principal (et dédupliquer dans ce cas) mais pas l'inverse. Par conséquent, de nombreuses dépendances locales transitives peuvent ne pas être aplaties en node_modules .

  Avec cette solution, Yarn peut continuer à garder une trace de tous les packages, les développeurs sont capables d'installer des éléments sans polluer leur dépôt, et nous préservons les builds reproductibles. (Il y a aussi de la place pour un package.local.json avec une section devDependencies , mais je ne suis pas sûr que ce soit nécessaire.)

• Les gens utilisent déjà des solutions de contournement pour obtenir ce qu'ils veulent de toute façon, au moins trois d'entre elles décrites dans les commentaires ci-dessus. Mais ils sont peu pratiques à utiliser, n'offrent pas les mêmes garanties et obligent les développeurs à lutter contre Yarn pour les comprendre. C'est le pire des deux mondes.

J'ai peut-être manqué quelque chose, mais cela semble être une conversation qui vaut la peine d'avoir.

J'ai un autre cas d'utilisation: j'aimerais qu'un module soit disponible dans REPL mais je n'ai pas l'intention de l'utiliser dans mon code. Dans l'état actuel des choses, je dois aller dans un dossier différent et y installer ce module, puis importer des fichiers json en utilisant ../other-project/data/xyz.json .

Mais si je veux importer un module et que cette chose importe d'autres modules en utilisant des chemins relatifs, eh bien, ça va casser.

Le simple fait de me laisser installer un module dans node_modules sans économiser rendrait les choses beaucoup plus faciles.

Je suis surpris de la résistance des responsables à cette idée.

Bonté moi, je viens de lire les commentaires précédents et l'attitude des responsables est décevante. Je développe de nombreux plugins spécifiques au framework qui ont des dépendances sur les bibliothèques de framework et je veux éviter de les ajouter en tant que dépendances dures dans mes plugins.

J'ai un plugin qui repose sur des packages spécifiques définis dans peerDependencies , maintenant le problème comme beaucoup d'autres personnes l'ont déjà commenté est de savoir comment installer les dépendances localement sans les ajouter dans le package.json fichier? Eh bien, vous ne pouvez pas.

La seule solution que j'ai trouvée est d'installer le peerDepencies tant que devDependencies qui ne semble pas du tout idéal, mais cela fonctionne autour du problème. Au moins npm dans son état horrible s'installe sans modifier votre fichier package.json .

@hpurmann @kittens

Avez-vous renoncé à répondre à la communauté? De toute évidence, ignorer ce problème ne vous rend pas service et ne disparaîtra pas. Quel est l'intérêt d'appeler cela un projet open source si vous n'allez même pas répondre à la simple question de savoir si quelqu'un fait le travail et soumet un PR, l'accepterez-vous?

J'aurais probablement dû répondre il y a quelque temps, juste après que @viveleroi ait expliqué son cas d'utilisation tout à fait valable (que beaucoup d'entre vous semblent avoir). À l'époque, j'ai fait des commentaires positifs sur sa réponse, ce qui n'est évidemment pas suffisant pour être noté.

J'ai changé d'avis. Habituellement, les gens veulent beaucoup de choses et si les responsables acceptent toutes les fonctionnalités, le logiciel devient gonflé. Je n'ai pas ce cas d'utilisation mais je vois que beaucoup de gens le souhaitent.

Je ne peux rien décider cependant. Je ne suis pas un responsable de ce projet.

@Vheissu Quel est le problème avec yarn add --peer <dep> ?

pour moi yarn add --peerfonctionne JUSQU'À ce que vous ajoutiez un autre paquet, à quel point les pairs deps existants sont supprimés de l'installation locale et vous devez les lire manuellement.

J'aimerais cette fonctionnalité car aujourd'hui parce que j'écris un exemple d'implémentation de ma bibliothèque en utilisant express, mais aucun de mes codes ne dépend directement d'express. Je ne veux rien installer ou dépendre d'Express, mais je veux l'installer dans mon répertoire actuel.

Tout comme @ brendan-hurley @suyanhanx , j'ai des dépendances que je veux installer dans CI et pas localement.
Je veux garder mes dépendances locales au minimum afin que nous n'ayons pas à gonfler node_modules et à nous coûter du temps et de l'espace pour chaque développeur travaillant sur le projet.

Packages nécessaires dans CI mais pas localement:

• Outils spécifiques CI: sémantique-release, greenkeeper-lockfile
• Outils de reporting de couverture: couverture de codage, combinaisons
• Outil de rapport de test pour CI: jest-junit, etc.

Voici pourquoi nous avons besoin de cette fonctionnalité:

L'utilisation de yarn link ne liera pas les dépendances du paquet, vous devez donc les installer dans
la destination liée - l'ajout de ces dépendances externes à package.json rend tellement gênant.

Soit yarn link doit ajouter des dépendances, soit fournir un moyen d'exclure la destination package.json

J'ai un cas d'utilisation assez ésotérique, mais cela me serait utile. Je comprends parfaitement pourquoi il est important que yarn.lock et package.json soient la source de la vérité, et que si j'utilisais une commande --no-save , mes modifications seraient effacées les yarn suivants

Cela dit, je souhaite que yarn me fasse confiance pour savoir ce que je fais et me permette de passer le drapeau --no-save . Si je rencontre l'un des cas problématiques, je saurai exactement ce qui ne va pas et que je n'ai que moi-même à blâmer. :sourire:

Mon cas d'utilisation?
Je lance une machine à gagner 64 bits.
La machine Prod est 32 bits.

La dépendance Node-sass que nous avons ne prend en charge que 32 bits à moins que nous ne mettions à jour le package.

Ne pas modifier la dépendance dans package.json ou yarn.lock pour prendre en charge une machine de développement.
Je voudrais donc installer localement le dernier node-sass pour prendre en charge 64 bits, mais n'affecte pas le package.json et yarn.lock

Je voudrais installer des packages @types/* dans des projets non-TypeScript sans altérer package.json / yarn.lock pour une meilleure autocomplétion dans VSCode.

J'utilise lerna avec un espace de travail de fil.
La définition de type d'Antd est interrompue en raison de la mise à jour @ types / [email protected] .
Antd résoudra ce problème le week-end.
Mais maintenant, je dois forcer le fil à installer une version fixe de @ types / [email protected] dans workspaceRoot manuellement sans affecter le package.json actuel (car il installera la dernière version automatiquement).

Conserver le comportement par défaut d'enregistrement dans package.json est correct, mais il existe des cas réels où le développeur doit installer le module sans affecter le package.json. Surtout quand il y a des changements de rupture inattendus dans certains packages.

La mise à jour implicite du package et l'enregistrement implicite dans package.json entraînent un conflit.

Voici un autre cas d'utilisation. Je maintiens une bibliothèque React. Avant de publier une nouvelle version, je souhaite exécuter mes tests sur plusieurs versions de react et react-dom , pour vérifier que mes modifications sont compatibles en amont et en aval ( @next ). Je faisais cela en utilisant la configuration ci-dessous, mais maintenant je veux utiliser les espaces de travail de Yarn, je dois donc migrer vers Yarn.

"test:backwards": "npm i [email protected] [email protected] --no-save && npm test",
"test:forwards": "npm i react<strong i="9">@next</strong> react-dom<strong i="10">@next</strong> --no-save && npm test",
"test:latest": "npm i react<strong i="11">@latest</strong> react-dom<strong i="12">@latest</strong> --no-save && npm test",
"test:compat": "npm run test:backwards && npm run test:forwards && npm run test:latest"

Je ne peux pas faire en sorte que ce script modifie mon package.json car cela ferait échouer ma commande de publication ( pack publish ) en raison de modifications non organisées.

Je souhaite ajouter des packages supplémentaires dans mon pipeline CI à des fins de test sans toucher au fichier package.json (il peut s'agir d'un montage de fichier en lecture seule).
Ceux-ci ne font pas partie des composants de développement.
Pendant le développement et les tests sur les machines de développement, ils ne doivent pas être installés et pendant la construction et la production, ils ne doivent pas être installés, ils ne sont jamais nécessaires et acceptables sur le serveur CI pendant les tests.

Cela fonctionne en utilisant simplement npm, mais le fil devrait être capable de supprimer la dépendance sur npm.
Cela pourrait très bien nous ramener à utiliser npm uniquement au lieu de fil uniquement.

De plus, cela brise tout simplement la promesse de pouvoir remplacer complètement npm, car il ne peut tout simplement pas faire ce que npm peut faire.

Aussi oui, cachez absolument cette fonctionnalité derrière un indicateur car cela ne devrait pas être un cas d'utilisation normal mais un cas d'utilisation de bord.

Est-ce que vous plaisantez ? 3 ans pour ajouter un simple interrupteur?

Un autre cas d'utilisation: nous utilisons un package npm ( git-hoooks ) pour les vérifications pré-commit. Tous les membres de l'équipe n'ont pas installé de nœud, donc l'inclure dans package.json annulerait les commits pour certaines personnes. J'essaie donc de créer des scripts npm pour activer / désactiver temporairement les hooks en installant / supprimant git-hooks. Très déçu de découvrir que cette tâche apparemment simple et facile est pratiquement impossible à accomplir avec du fil.

Si le souci est que yarn.lock ne sera plus une source de vérité pour le contenu de node_modules, eh bien, qu'est-ce qui est si mauvais à ce sujet? Les fonctions existantes ne pourraient-elles pas simplement ignorer l'existence des dépendances non suivies? Yarn est un excellent outil et les mainteneurs ont rendu un excellent service à la communauté JS, mais ils doivent reconsidérer cette décision.

Est-ce que vous plaisantez ? 3 ans pour ajouter un simple interrupteur?

@spanasik et @Ryuurock : soyez poli lorsque vous

Cela n'a pas pris "3 ans" parce que le commutateur est trop compliqué à implémenter - c'est parce que les responsables ne sont pas convaincus que ce sera un avantage net pour les utilisateurs. Si vous n'êtes pas d'accord avec cela, faites un argument pour la fonctionnalité.

@NickHeiner voici 10 écrans d'arguments. Et le principal qui suscite la frustration, ce n'est pas que les responsables ne soient pas convaincus, mais qu'ils l'ignorent, ne répondent pas aux arguments, lorsque les gens "ne sont pas d'accord avec cela, argumentent pour la fonctionnalité". Et quand les gens sont frustrés, ils laissent bien sûr des commentaires désagréables. Veuillez ne pas rejeter la faute sur les utilisateurs.

Je conviens qu'il serait préférable que les responsables abordent la discussion ici. Il y a clairement un intérêt de la part d'un large éventail de personnes sur plusieurs années. Alors peut-être que ma suggestion selon laquelle @spanasik et @Ryuurock devraient simplement "argumenter" est déraisonnable, car elle serait probablement ignorée comme tout le reste ici.

Et quand les gens sont frustrés, ils laissent bien sûr des commentaires désagréables. Veuillez ne pas rejeter la faute sur les utilisateurs.

Je ne suis pas d'accord. Cette grossièreté n'est toujours pas un pas en avant utile, ni un comportement acceptable chez les adultes. Etre impoli est un excellent moyen de justifier que les responsables ignorent cela davantage: "le fil n'est que des trolls".

Des moyens constructifs pour aller de l'avant:

1. Attirez l'attention des responsables sur ce fil sur d'autres canaux (peut-être qu'ils l'ont ignoré) et demandez-leur au moins de reconnaître les arguments ici, même s'ils ne sont pas d'accord.
2. Fourchez / remplacez le fil et gérez le projet d'une manière dont les gens sont plus heureux.

L'astuce pratique est yarn add --dev pkg && yarn remove pkg . Cela fait la même chose. Le fichier de verrouillage reste tel qu'il était avant cela, donc intact.

Testé - ne fonctionne pas.

Mon cas d'utilisation est le suivant:
Certains packages ont des compléments facultatifs chargés avec «require». Je ne veux pas ajouter ces compléments à la section devDependencies donc je fais un 'yarn add my-add-in' et je le supprime manuellement du fichier package.json. Sur mon pipeline Cloud CI, j'utilise 'npm je' les ajoute (pour les tests). Sur mon pipeline local, je ne veux pas utiliser npm car il crée un fichier de verrouillage supplémentaire. Ma meilleure option maintenant est d'utiliser npm, puis de supprimer leur fichier de verrouillage (pour supprimer la deuxième version apparente de la vérité).

Donc, après avoir tout lu, ma question aux responsables est la suivante:

• Pourquoi es-tu si incohérent?
• Pourquoi ne pas mettre en œuvre cette philosophie à travers chaque fonctionnalité?
  
  
  
  • C'est-à-dire: Décidez comment les choses doivent être faites pour nous tous et supprimez toutes les autres options de toutes les fonctionnalités. Gardez le cap! Rester fidèle à vous-même!
  
  

Le fait indéniable est que tous les bons logiciels ont des paramètres de configuration car un bon logiciel permettra à l'utilisateur de choisir ce qui convient le mieux à sa situation . Et toujours toucher le fichier 'package.json' est une bonne pratique - mais il existe des cas de bord où 'yarn' n'est tout simplement pas à la hauteur à cause de cette philosophie.

J'aime vraiment le fil parce que c'est simple et rapide . Il est vraiment dommage que les responsables mènent une bataille qu'ils sont sûrs de perdre - parce que la communauté est obligée de revenir à un npm fiable et lent pour que les choses fonctionnent.

Baissons un peu la température. Personne n'a besoin de se sentir dégoûté par un
logiciel qu'ils sont autorisés à utiliser gratuitement.

Le mer 15 janvier 2020 à 23:17 Hajime Yamasaki Vukelic <
[email protected]> a écrit:

Je suis dégoûté que le fil me fasse travailler d'une certaine manière. J'aime
décider moi-même, et je n'aime pas que mes outils me disent comment je
devrait fonctionner, insulter mon intelligence étant le moindre des problèmes, et
ne pas pouvoir faire avancer les choses est de loin le plus important.

Croire aux règles parfaites et qu'il n'y aurait jamais lieu de
les briser est naïf. Il y a une différence entre les "meilleures pratiques" et
"fais ou meurs". Comme le dit Oliver Wendell Holmes Sr.:

Le jeune homme connaît les règles, mais le vieil homme connaît les exceptions.

-
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/1743?email_source=notifications&email_token=AAGKTAZRWD3XJQEGH5N5RL3Q6ACZNA5CNFSM4CVUKFMKYY3PNVWWK3TUL52HS4DFVBE17WWWWK3TUL52HS4DFVBE175WWWK3TUL52HS4DFVBE175WWWK3TUL52HS4DFVBE175WWWK3TUL52HS4DFVBE175WWWK3TUL52HS4DFVBE175WWWWK3TUL52HS4DFVBE
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/AAGKTAZSB4FNAIFLZIL547LQ6ACZNANCNFSM4CVUKFMA
.

Créez votre propre gestionnaire de paquets, personne ne vous oblige à faire quoi que ce soit.

Pas du tout en colère, il suffit de signaler l'erreur dans votre logique:

le fil me fait travailler d'une certaine manière.

Le fil ne vous fait rien faire, ils ont créé un outil (gratuitement) et cela fonctionne d'une certaine manière. Si vous ne l'aimez pas, utilisez autre chose.

@foxbunny J'apprécie que vous

Même si vous pensez que c'est raisonnable et que vous vous sentez dégoûté dans ce cas, je ne pense pas que la langue soit une façon polie de parler aux personnes qui ont construit cet outil disponible gratuitement pour vous. Vous pouvez donner des commentaires constructifs tout en étant respectueux.

@whitecolor l'équipe a

S'il vous plaît arrêter

Ou que diriez-vous que tout le monde utilise simplement l'outil qui fonctionne comme il le pense et se calme.

Mon cas d'utilisation est

Je souhaite mettre à jour la sous-dépendance de notre application
Je lie cette dépendance avec yarn link
J'utilise ensuite un lié dans notre application
J'ajoute des dépendances dans notre bibliothèque
La dépendance lib ajoutée n'est pas installée dans l'application principale après yarn install (wtf n ° 1)
Ensuite, je pense, ok, ajoutons-le rapidement sans enregistrer dans l'application afin que je puisse simplement vérifier si les choses fonctionnent avant de publier la mise à jour sur notre lib
Mais - non.

Merci

Désolé de voir la communauté ignorée par les auteurs.

En tant que bénévole open source, il faut avoir une philosophie cohérente ou la
projet se dégradera en une boule de boue. Cela signifie parfois dire
les gens «non». Si vous n'êtes pas d'accord, vous pouvez créer votre propre package
manager, tout comme le fil a remplacé npm.

Le mar 3 mars 2020 à 03:53 Artur Kwiatkowski [email protected]
a écrit:

Désolé de voir la communauté ignorée par les auteurs.

-
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/1743?email_source=notifications&email_token=AAGKTA4K3STUMXFRUDMPJU3RFTVTLA5CNFSM4CVUKFMKYY3PNVWWK3TUL52ississ4DFVREXG43TUL52ississ4DFVREXG43TUL52ississ4DFVREXG43TUL52ississ4DFVREXG63
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/AAGKTA7WL4R3R47HBU6EPI3RFTVTLANCNFSM4CVUKFMA
.

J'utilise Lerna, et je veux vraiment installer _only_ Lerna dans l'une de mes étapes CI, pour l'étape de publication, car le projet est déjà construit dans une étape précédente et les artefacts reportés. Est-ce un scénario valable?

^ mon commentaire original - honnêtement, je ne sais pas pourquoi j'aurais jamais eu besoin de ça, et je ne savais pas que ce fil exploserait si horriblement - mais c'est amusant de voir des e-mails à ce sujet des années plus tard.

Je suis enclin à être d'accord avec les responsables ici:

1. Je ne suis pas convaincu par mon propre argument. Je suppose que les responsables ont été polis en ne disant pas que c'était un argument stupide.
2. Même si quelqu'un «fait» un PR, cela signifierait que la maintenance continue de la fonctionnalité serait le fardeau supplémentaire des responsables, les empêchant de maintenir le produit principal.
3. Ce type de caractéristique serait mal utilisé par des débutants modestes et / ou des consommateurs de fil relativement peu qualifiés, ce qui perpétuerait encore le point 2.

Dans tous les cas, il existe probablement un moyen meilleur et plus sain sur le plan architectural pour atténuer le besoin de cette fonctionnalité.

J'ai créé yarn-add-no-save pour obtenir cette fonctionnalité. Il peut être installé localement dans votre projet ou globalement:

$ yarn add yarn-add-no-save --dev
# or
$ yarn global add yarn-add-no-save

Une fois installé, vous pouvez simplement exécuter:

$ yarn add-no-save <packages> # (yarn-add-no-save when installed globally)

Mon cas d'utilisation est de tester des modules qui déclarent peerDependencies afin que l'outil dispose de quelques options pour les installer automatiquement, pour voir toutes les options s'exécuter:

$yarn add-no-save --help

REMARQUE: je suis conscient que sauvegarder un paquet pour installer des paquets sans les sauvegarder est ironique et va fondamentalement à l'encontre de l'objectif, mais c'est le meilleur que je puisse proposer et cela répond à mes besoins.

Ceci est très utile, en particulier le support peerDeps. Je vous remercie.

Il existe plusieurs bons arguments en faveur de cette fonctionnalité. Ce n'est pas comme le faire par défaut, les gens demandent que ce soit derrière un drapeau clair que seules les personnes qui en ont besoin l'utiliseront. Actuellement, comme certains autres, je dois faire des tests pendant CI avec d'autres versions de bibliothèques que je ne veux pas enregistrer . Je ne peux pas comprendre ce qui est si difficile à comprendre ici.

Je dois yarn install xxx puis yarn remove xxx .

Je ne sais pas si ce cas d'utilisation a déjà été discuté. Laissez-moi essayer d'expliquer ma situation - j'ai un tas de packages interdépendants les uns des autres dans un dépôt. Ils utilisent tous les mêmes dépendances externes avec un package commun au niveau des sous-projets de maintenance racine en dessous, chaque package local doit être construit dans l'ordre du suivant à consommer. J'essaye d'utiliser des espaces de travail de fil pour cela. Pour commencer, je n'ai pas de packages locaux définis dans mon package.json racine. Après un cycle complet de construction de tous les composants, je finis par avoir un package.json racine entièrement mis à jour avec ces dépendances locales. Maintenant, lorsque cette mise à jour sera construite sur CI, tous ces packages locaux ajoutés échoueront en raison de la non-disponibilité. Nous devons supprimer ces entrées nouvellement ajoutées pour que cela fonctionne dans CI.

Je dois yarn install xxx puis yarn remove xxx .

le même

Voici un cas d'utilisation pour vouloir pouvoir le faire:

Nous construisons un outil avec un écosystème modulaire pour les «appliances» au sein de l'outil, et le plan est pour une instance locale d'être mis en place avec ces appliances, et de les activer dynamiquement via la configuration. Les appliances sont publiées sur npm (et peuvent être appelées en dehors de notre framework si quelqu'un le souhaite).

Le projet vanilla ne dépend PAS package.json serait inapproprié. La configuration d'une instance spécifique peut exiger que l'un des packages soit installé localement.

L'absence de cette fonctionnalité semble être une décision limitative pour notre projet, même si nous continuerons à explorer des approches alternatives.

Avant de lire la réponse des «responsables» ici, je pensais que j'étais la personne la plus têtue de tous les temps.

Presque 4 ans ... 🤦

«L'entêtement» n'est pas la même chose que «avoir une vision du design et ne pas mettre en œuvre tout ce que quelqu'un demande».

«L'entêtement» n'est pas la même chose que «avoir une vision du design et ne pas mettre en œuvre tout ce que quelqu'un demande».

La vision du design décrit le chemin heureux, et les trappes d'évacuation comme celle demandée ici, ajoutent à l'utilité pour la communauté au sens large.

Pourquoi ne pas simplement ajouter une section au fichier de verrouillage qui garde une trace des installations "freeform" et des instantanés incrémentiels du statu quo (en node_modules ), pour les rendre réversibles en toute sécurité? Ou peut-être mettre les dépendances dans un dossier séparé de node_modules, et utiliser node_modules juste pour garder les liens exposés à son package, afin que Yarn puisse réellement gérer tout seul et ne pas s'inquiéter de l'écrasement et de la rupture des installations invisibles.

Git a résolu ce problème des décennies avant vous, rattrapez votre retard! Trouvez quelque chose! C'est ce qu'est le design - contourner les limites, plutôt que de les combattre (ou de leur céder).

La vision tunnel aux deux extrémités ici est née de l'ignorance, d'une réflexion excessive et d'une polarisation inutile. Il n'y a ni arts martiaux, ni philosophie, ni révolution, ni politique; il y a juste un outil, un tas de code et un travail à faire. Si l'outil ne peut pas aider à faire le travail, ce n'est pas un outil pour ce scénario particulier. Et pour un outil prétendant être un outil polyvalent complet, comme Yarn, il y a tellement de scénarios courants négligés ici qu'il creuse simplement sa propre tombe.

J'ai l'impression que tout le monde se pousse sur une colline étroite alors que nous pourrions simplement la contourner.