<p>yarn ne devrait probablement pas mettre en cache les packages résolus avec un chemin de fichier</p>

Cela m'a aussi trompé. Il doit y avoir un moyen de contourner ce problème sans effacer tout le cache.

Je pense qu'il pourrait y avoir trois façons de rendre le fil utilisable dans ce cas:

1. Suggestion de
2. Réinstaller les dépendances locales si un fichier y est modifié plus tard que lors de sa mise en cache. Cela nous obligerait à conserver ces métadonnées. Pour les dépendances locales, nous pouvons insérer des lignes comme celle-ci dans la colonne "Résolu": file://<path>@<cache_timestamp>
3. Ignorer les packages par nom de package avec des commandes telles que yarn cache rm <package> et yarn cache add <package> . Pour toutes les dépendances.

J'aimerais voir la deuxième suggestion à mettre en œuvre. À moins que la troisième option ne soit également utile pour d'autres cas. Par exemple, yarn cache add <package> peut être utilisé pour actualiser le cache pour les dépendances déjà mises en cache au cas où quelque chose pourrait mal tourner lors du téléchargement d'une dépendance.

@hantuzun pourquoi mettre en cache les dépendances locales? ils sont de toute façon locaux, donc ce sera rapide indépendamment de la mise en cache ou non.

@ satya164 vous avez raison. Bien que je sois plus enclin à la troisième approche, cela aiderait si une dépendance du réseau est modifiée intentionnellement.

Quelque chose comme yarn cache ignore <package> sera utile. Mais je pense qu'ils ne doivent pas être mutuellement exclusifs. Ignorer un paquet est utile, mais cela nécessite un travail manuel. Les dépendances de fichiers pourraient fonctionner sans effort supplémentaire si elles étaient ignorées par défaut.

Quelqu'un peut-il m'expliquer la logique interne?

Ma compréhension:
Lorsqu'une dépendance avec file: est rencontrée, le file-resolver.js en jeu. Il indique que la dépendance doit être copiée et n'est pas hachée . L'absence de hachage ne signifie-t-elle pas qu'il ne devrait pas déjà être mis en cache ...? Mais le copy-fetcher.js semble définir le hachage sur une chaîne vide au lieu de garder null ... Est-ce problème?

@bestander ou @kittens Peut-être

Hash signifie le hachage md5 qui est utilisé pour tarball-fetcher, par exemple.
Ce hachage est ensuite ajouté au fichier yarn.lock pour les vérifications futures et également ajouté au nom du dossier lors de l'enregistrement du dossier décompressé dans le cache.
Vous creusez dans la bonne direction, merci de vous pencher sur cette question, un PR est le bienvenu.
Vous pouvez probablement commencer avec un PR qui ajoute un test unitaire cassé

Vous pouvez probablement commencer avec un PR qui ajoute un test unitaire cassé

D'accord, merci pour votre réponse. Dois-je vous cingler en tant que critique dans le PR ou dois-je cingler quelqu'un d'autre (ou personne) ...?

Ouais, envoie-moi un ping

@bestander probablement ce problème ne devrait pas être fermé car il n'est pas encore résolu?

Oui, il devrait être rouvert. Il a été fermé car j'ai écrit "corrections # 2165" dans le titre de mon PR. Au début, je pensais que ce serait un PR en cours, mais pour corriger ce bug, nous voulons deux PR: le premier a ajouté un test unitaire (l'assertion qui échouerait n'est pas vraiment active, donc CI n'explose pas) et le le second le réparera.

Désolé, github résout les problèmes lorsque PR est fusionné

donc évidemment c'est toujours un problème? c'est assez ennuyeux de développer avec, pour être honnête. cela me perturbe un peu sur le plan personnel au travail, où j'utilise file: pour créer un environnement de développement modulaire. le truc, c'est que chaque paquet local que j'édite (en utilisant le chemin file: dans package.json ), nécessite de faire ceci, afin d'extraire le contenu actualisé:

éditer le contenu de mon paquet eslint-config-base-eslint

yarn cache clean && rm -rf node_modules/eslint-config-base-eslint && yarn install --force && yarn lint

Tout le monde est invité à contribuer au projet.
Cela peut être n'importe quoi - soumettre un test d'intégration cassé pour ce cas, un correctif ou convaincre quelqu'un de travailler sur le correctif.
Si vous souhaitez discuter de la meilleure façon d'aborder cela, vous pouvez trouver de l'aide sur le canal Discord.

Je pense en fait que le correctif devrait être de 10 à 15 lignes de code, cela gagnera probablement beaucoup de temps à le réparer plus tôt

FYI: Il se peut que ce problème soit également pertinent pour les étapes lentes linking dependencies . Voir mon commentaire ici: https://github.com/yarnpkg/yarn/issues/1496#issuecomment -282688818.

Désolé. Je n'ai pas trouvé le temps de créer un autre PR pour ce problème: (J'étais (et je suis toujours) très occupé.

@bestander C'est un gros bloqueur pour moi, travaillant sur un projet multi-module. Si je lis correctement les liens de code et les commentaires de hash (au lieu de null) chaque fois qu'il essaie de résoudre afin qu'il force une réinstallation? Dites un UUID ou un horodatage actuel? Pardonnez-moi si quelque chose me manque, je ne suis pas familier avec le fonctionnement du code.

Un nouveau cache avec un horodatage et un uuid sonne comme un hack raisonnable.
Idéalement, nous devrions copier les fichiers directement sans le cache, mais cela peut être un
changement plus complexe.
Allez-y, envoyez un PR

Le mar 7 mars 2017 à 03:38, Matt Traynham [email protected] a écrit:

@bestander https://github.com/bestander C'est un assez gros bloqueur
pour moi, travaillant sur un projet multi-modules. Si je lis @donaldpipowitch
https://github.com/donaldpipowitch liens de code et commentaires
correctement, pourrions-nous demander au résolveur de fichiers de créer un nouveau hachage (au lieu de
null) chaque fois qu'il essaie de résoudre, il force donc une réinstallation? Dites un UUID
ou horodatage actuel? Pardonne-moi si je manque quelque chose, je ne suis pas familier
avec la façon dont le code fonctionne.

-
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/2165#issuecomment-284612526 , ou muet
le fil
https://github.com/notifications/unsubscribe-auth/ACBdWDS3xSr8KNu1o9Zn8sA9xdO8pyHOks5rjNEmgaJpZM4LFbmf
.

@bestander Concernant votre dernier commentaire: Ne serait-il pas encore plus logique de créer un lien symbolique au lieu de copier les fichiers? Ou y a-t-il une raison de ne pas le faire?

@danrot windows semble exiger de l'administrateur un lien symbolique.
aussi il gâche la récursivité pour trouver des modules de nœuds

Symlink ignore également .npmignore et des trucs comme ça. (Ce qui semble actuellement ignoré, aussi. Ce qui pourrait être problématique: https://github.com/yarnpkg/yarn/issues/1496#issuecomment-282688818)

Existe-t-il une solution de contournement pour cette interdiction actuelle de vider tout le cache? Malheureusement, il ne semble pas y avoir de commande de type yarn cache rm package .

@ rhys-e J'utilise ce petit script:

#!/bin/sh
if [ $# != 1 ]
then
   echo Usage $0 package-name
   exit 1
else
    echo Reinstalling $1
fi

dir="node_modules/$1"

if [ -d $dir ]
then
    rm -fr $dir
fi

cache=`yarn cache dir`/npm-${1}*
#        echo $cache
rm -fr $cache && yarn install --force

Quelqu'un a-t-il essayé de yarn link toutes les dépendances locales sur postinstall ? Cela ressemble à une solution appropriée jusqu'à ce que la solution appropriée se pose.

Je suppose que l'idée est de ne pas avoir à mettre à jour le numéro de version du package à chaque changement pour les dépendances locales. Un lien de fil vous obligerait à faire ça, non? (n'a pas essayé)

De mon côté, ce que j'ai finalement fait est d'appeler un script sur la phase de pré-installation qui compare ce qui se trouve dans le dossier source et le dossier node_modules pour les dépendances locales. S'il détecte une différence, il supprime simplement la dépendance mise en cache et supprime le fichier d'intégrité (pour forcer une réinstallation). Ainsi, quand il n'y a pas de changement, l'installation de fil est assez rapide (il n'y a pas beaucoup de dépendances locales) et s'il y a la version mise en cache obsolète n'est pas utilisée.

@lucdew link créera essentiellement un lien symbolique sous le capot, ce qui signifie que la dernière version locale sera utilisée. Mais je pense qu'avoir un script, qui avant l'installation nettoie le cache de déps spécifiques est la bonne solution pour le moment.

J'ai testé différentes combinaisons pour contourner les modifications du package local qui ne sont pas mises à jour dans la version installée d'un projet parent sous ./node_modules/. Je trouve que cela suffirait, sans avoir besoin de supprimer le ./node_modules/première:

yarn cache clean; yarn upgrade file:../<package>

Inutile de dire que forcer manuellement le nettoyage global du cache ne devrait pas être nécessaire pour mettre à jour / mettre à niveau les packages locaux.

@fungilation Pour contourner le

Par # 2860 et le commit de fusion suivant https://github.com/yarnpkg/yarn/commit/7241de13bb236526fa439a2528fbed319f60ef24 , vous pouvez maintenant "rafraîchir" file: les dépendances de protocole avec

yarn install --force

Modifier ou mettre à jour le package particulier (je ne savais pas que cela fonctionnait également). Si la version des dépendances n'a pas changé, cela ne modifie pas le fichier de verrouillage, mais cela copiera toujours la version la plus récente vers le bas.

yarn upgrade [file protocol package name]

Le changement de PR invalidera la dépendance dans le cache et le réinstallera localement. yarn install fonctionnera également si la version des dépendances a changé, ce qui invalide le fichier yarn.lock. Vous n'avez plus besoin de vider le cache, ni de supprimer le module de l'installation locale.

Il m'est également apparu qu'il existe un RFC actif pour lier les dépendances, éventuellement avec un protocole link: . Cela peut être suivi ici, https://github.com/yarnpkg/rfcs/pull/34.

@mtraynham Merci pour votre pull request! 👌 C'est génial. Des raisons pour lesquelles --force est nécessaire? Actuellement, je ne sais même pas ce qu'il fait exactement en ce moment sans le chercher :) Juste demander, car npm n'a pas besoin d'un drapeau --force et cela aurait été bien de se comporter comme npm.

Modifier On dirait que yarn upgrade [dependency] fonctionne également. Je tiens à souligner que cela ne modifie pas toujours le fichier de verrouillage, qui ne devrait refléter que les changements de version de package.json. J'ai mis à jour mon message d'origine, car une mise à niveau est probablement plus appropriée.

La version courte est, Yarn ne fera rien avec les résolveurs de cache si le fichier de verrouillage n'a pas changé, nous devons donc ignorer la vérification du fichier de verrouillage et demander au cache s'il existe une version plus récente. Cela peut être fait en utilisant upgrade ou install --force

Par yarn install --force documentation

"il remet à jour tous les paquets, même ceux qui étaient précédemment installés".

Cela signifie vraiment qu'il ignorera la vérification de l'intégrité du fichier de verrouillage. Le contrôle d'intégrité du fichier de verrouillage réussira généralement si vous ne modifiez pas le fichier package.json et que vous ne le sortez pas correctement. Sauter cela demande au cache de vérifier les dépendances manquantes / incompatibles avec le fichier de verrouillage, de les télécharger si manquantes et de recopier localement toutes les dépendances plus récentes / manquantes. Ensuite, il exécute npm install / postInstall scripts.

Le changement de PR invalidera désormais la dépendance file: dans le cache et copiera la nouvelle version localement. Avant cela, il n'invaliderait jamais la dépendance file: . Pour les autres protocoles, si vous n'avez pas modifié votre fichier package.json, ils resteront inchangés (dans le cache et localement).

Alors qu'est-ce que cela signifie pour nous? J'ai environ 60 dépendances sur un projet (allant de Angular à Webpack), avec une dépendance file: . Sur un deuxième install --force , où je souhaite uniquement actualiser la dépendance locale, cela prend environ 5 secondes (contre environ 1,5 seconde pour yarn install ). Pour moi, c'est assez négligeable, et je suis en fait très impressionné par le peu de fil de travail qui essaie de fonctionner tout au long du processus.

S'il existe une autre commande CLI pour ignorer la vérification du fichier de verrouillage et vérifier le cache uniquement pour la dépendance de fichier particulière, ce serait probablement encore plus rapide, mais je n'en ai pas trouvé.

Cela étant dit, j'appellerais toujours cela un pansement. Cela pourrait être remplacé par une meilleure solution telle que link: ; Je ne pense pas que quiconque se soucie vraiment de cacher les dépendances locales. À tout le moins, les frais généraux supplémentaires liés à l'utilisation de install --force ou upgrade sont principalement négligents et vous n'avez plus à yarn cache clean; mv node_modules /tmp/ .

Très bonne réponse. 👏 Merci d'avoir noté ceci.

Yarn écrase-t-il les fichiers de projet locaux liés par un lien symbolique avec les fichiers du cache de Yarn? (car on dirait que c'est ce qui se passe)

Le changement de PR invalidera désormais le fichier: dépendance dans le cache et copiera la nouvelle version localement.

Cela signifie-t-il que chaque fois que j'appelle $ yarn dans un package qui a "foo": "file:../" comme dépendance, une nouvelle copie de "file:../" sera créée?

Par exemple, j'ai un package avec plusieurs exemples qui sont également des packages:

foo/
foo/examples/
foo/examples/example-1/
foo/examples/example-2/
foo/examples/example-3/
...
foo/examples/example-10/

Et il semble que j'ai foo 10 fois maintenant dans le cache de fils. Je teste également mes exemples sur chaque changement de version de foo (et j'ai plusieurs modules configurés de cette manière, pas seulement foo ), donc il semble que mon cache de fils se développe _really_ rapidement actuellement.

Est-ce le bon comportement?

Je pense que c'est une meilleure alternative que d'avoir une version périmée dans votre cache.
Avec yarn 0.26, vous pouvez utiliser link: pour créer des liens symboliques au lieu de copier des fichiers.
Nous travaillons également sur des espaces de travail qui automatiseront la création du lien symbolique, https://github.com/yarnpkg/yarn/issues/3294

Ouais, dans l'attente des espaces de travail 👍

link: ne fonctionne pas encore avec npm, non? (Parce que https://github.com/npm/npm/pull/15900 est toujours ouvert.)

À partir de npm 5 patchnote , les fichiers sont désormais automatiquement liés par un lien symbolique avec la syntaxe file: :

npm install ./packages/subdir créera désormais un lien symbolique au lieu d'une installation normale. file: //path/to/tarball.tgz ne changera pas - seuls les répertoires sont liés par un lien symbolique. (# 15900)

Alors oui, il n'y a pas de link avec npm.

npm install ./packages/subdir créera désormais un lien symbolique au lieu d'une installation régulière

Un peu malheureux. Les déps de fichiers ne se sont jamais comportés de la même manière en raison de tout copier (y compris node_modules ) et de ne pas respecter le champ .npmignore ou files . Maintenant, c'est pire avec le lien symbolique.

Je pense que file: and link: pourrait être amélioré, il existe différentes stratégies qui ont leurs propres avantages et inconvénients et Yarn devrait permettre aux gens d'en choisir une.
Par exemple, knit RFC pourrait être implémenté comme l'une des stratégies https://github.com/yarnpkg/rfcs/blob/master/accepted/0000-yarn-knit.md

@bestander

Je pense que c'est une meilleure alternative que d'avoir une version périmée dans votre cache.

Ou alors vous croyez jusqu'à ce que vous manquiez d'espace disque et que votre cache Yarn utilise des dizaines de gigaoctets pour des millions de fichiers totalement inutiles .
IMO qui rend le tout plus gravement cassé qu'auparavant, car vous ne le découvrez qu'une fois que vous avez temporairement cassé votre système de développement.

Salut les gars, des mises à jour sur le problème? C'est vraiment un énorme problème pour nous, surtout lorsque nous travaillons sur plusieurs produits à la fois qui dépendent des mêmes multi-dépendances liées. Gigaoctets de cache dans une journée de développement, etc. Pourriez-vous au moins le rendre facultatif et désactiver la mise en cache pour de tels paquets?

@nikdojo Utilisez le link: pour les dépendances au lieu de file: , il utilise des liens symboliques. Il a été introduit en 0.26 .

Vous pouvez également commencer à utiliser les espaces de travail si vous avez de nombreuses dépendances inter-projets.

@mtraynham Thx pour l'indice, j'ai essayé de trouver des informations link: protocole

@bestander btw comme vous le savez,

Cela n'a jamais été résolu, n'est-ce pas? Vous devez utiliser linklocal (packages NPM) pour lier les packages locaux (ce qui devrait être la manière standard dont yarn fonctionne lors de la consommation de packages à partir d'un système de fichiers local - en utilisant des jonctions ou des liens symboliques sur Windows au lieu de la mise en cache). Un nouveau yarn install écrase alors tout avec les anciens éléments du cache et vous devez recommencer la liaison.

Pouvons-nous être moins astronaute d'architecture et simplement ne pas cacher les paquets locaux? Ce problème a maintenant 1,5 ans et j'en ai assez d'exécuter yarn add ../<another-local-package> chaque fois que je change quelque chose dans another-local-package .

Salut @fungilation
J'ai ouvert un autre problème connexe: # 6037

ne marche pas
J'ai mis dans le fichier App.js
console.
puis supprimez tous les fichiers et il effectue toujours la sortie du cache.
Comment éviter cela?

Yarn m'a vraiment échoué sur cette question. Ça a été génial pour tout le reste, sauf pour ça.

J'ai essayé d'installer une nouvelle version d'un paquet local à des fins de test, et je continue à me retrouver avec l'ancien paquet quoi que je fasse.

J'ai essayé:

1. Nettoyage du cache de fil ( yarn cache clean package-name )
2. yarn add avec --force
3. Suppression de nouveau de node_modules/package-name et de yarn add
4. Mise à jour du numéro de version et du nom de fichier du paquet local ( yarn installe toujours le contenu de l'ancienne version , même s'il signale l'installation de la plus récente)
5. Combinaisons de tout ce qui précède

C'est ridicule, et j'y ai passé presque 4 heures de ma journée.

Nous avons besoin de la capacité de développer et de réinstaller des packages locaux . Je compte sur yarn pour installer un fichier dans le dossier .bin, donc yarn link est hors de question.

@ Yarn Developers: Pouvez-vous installer un package local, apporter des modifications à ce package local, puis faire en sorte que les modifications soient reflétées en réinstallant?

@gregjacobs j'ai eu du succès avec yarn install --force

@jonathantorley Je viens de l'essayer à nouveau avec --force et cela ne fonctionne toujours pas avec le fil 1.12.3

Pour les autres confrontés à ce problème: une solution de contournement que j'ai utilisée pour que cela fonctionne était d'augmenter le numéro de version du package dépendant. Un peu ennuyeux, et vous devez vous rappeler de le faire à chaque changement (sauf si vous pouvez le script).

yarn ne devrait certainement pas nécessiter cette solution de contournement lors de l'installation de packages locaux

J'ai ajouté yarn upgrade MY_PACKAGE_NAME dans le script preinstall , et il passe bien à la dernière version de NPM. (Pourtant, j'ai besoin de bosse la version NPM manuellement).

Il semble que yarn add file:PATH jour toujours le nouveau contenu maintenant dans le fil 1.13.0.
yarn install toujours pas.

@leavesster n'est toujours pas pour moi.

Je dois renommer le tgz pour qu'il se mette à jour

Essayez d'utiliser la commande link : https://yarnpkg.com/lang/en/docs/cli/link/

yarn add file:PATH n'a pas mis à jour le nouveau contenu pour moi. De plus, les fichiers dans package.json et .npmignore ne sont pas respectés.

Cela fonctionne si vous changez la version de votre package.

Si vous voulez que yarn add file:PATH respecte les fichiers dans package.json et .npmignore, vous devez exécuter yarn pack dans votre dépendance de package locale, puis là où vous voulez l'installer, exécutez yarn add file:path-to-local-pacckage.tgz

Essayez d'utiliser la commande link : https://yarnpkg.com/lang/en/docs/cli/link/

yarn link n'est pas destiné à répondre au même problème. Ce n'est pas bon si quelqu'un veut le package npm comme s'il avait été publié en respectant les fichiers dans package.json et .npmignore

@leavesster n'est toujours pas pour moi.

Je dois renommer le tgz pour qu'il se mette à jour

Je n'ai pas de tgz dans mon package que j'utilise yarn add file: PACKAGE_PAH pour l'ajouter dans le projet en cours. J'ai juste du code js dans mon package. Peut-être que tgz est toujours faux?

Ne fonctionne pas pour moi non plus

@bestander pourquoi ce problème est-il fermé? Yarn met toujours en cache les fichiers locaux et les packages tgz. Les espaces de travail ne sont pas une solution dans certains cas, par exemple si un package a deps avec des versions spécifiques, et un autre package a devDeps les mêmes packages que le premier, mais avec une autre version, et si vous liez un package à un autre, votre projet a été interrompu .

J'ai le même problème que @gregjacobs. yarn cache clean package n'a pas aidé. Mais j'ai compris que si vous installez yarn add path/to/package.tgz puis remplacez l'archive par une autre, vous pouvez installer une nouvelle version simplement changer le chemin comme yarn add path/to/../to/package.tgz , donc le chemin absolu est le même, mais pour le fil c'est différent .

Je ne comprends pas où d'autre yarn stocke les packages mis en cache par chemin de résolution, même yarn cache list --pattern package est vide.

Je pense que le problème est quelque part ici https://github.com/yarnpkg/yarn/blob/eb2b565bb9b948e87b11119482ebc184a9d66141/src/resolvers/exotics/tarball-resolver.js#L58 -L63

Que ce passe-t-il:

• À partir de l'url path/to/package.tgz génère du hachage (c'est pourquoi path/to/package.tgz et path/to/../to/package.tgz résultats vers différents hachages)
• Avec ce hachage crée un répertoire temporaire pour le package (comme celui-ci /Users/kich/Library/Caches/Yarn/v4/.tmp/c019816ee7d10ed5e1fef4072e8cc617 )
• Pour la première exécution isValidModuleDest retournez false et tout va bien
• Paquets Tarball extraits dans ce répertoire
• Fichiers de ce répertoire installés dans le projet
• Vous modifiez les sources du projet de développement et créez / compilez la nouvelle archive tar du package avec le même nom et le même emplacement que le précédent
• Et vous essayez d'installer une nouvelle archive tar, mais le hachage généré est le même qu'avant et le répertoire temporaire n'a pas été effacé après la première exécution
• Donc à ce moment-là isValidModuleDest return true
• Et yarn installe l'ancienne version de votre package
• Vous exécutez yarn cache clean package , mais le répertoire temporaire reste intact

@bestander pouvons-nous simplement supprimer le répertoire temporaire ici https://github.com/yarnpkg/yarn/blob/master/src/config.js#L431 ?

Face au même problème, le cache sous le dossier temporaire prend 10 Go après que je travaille sur mon pacakge local pendant une seule journée!

Pouvons-nous rouvrir ce numéro? Nous sommes confrontés au même problème. Deux projets référençant un autre package via fichier:. Après quelques builds dans notre serveur CI / CD, le dossier cache commence à occuper beaucoup d'espace.

Je pense que le protocole de liaison est la meilleure solution pour cela, file: // ne fonctionne pas car il nécessite toujours un nettoyage manuel des caches et une installation forcée

https://github.com/yarnpkg/yarn/issues/2165#issuecomment -345825904

faites simplement de votre dépendance quelque chose comme ça

"<package>": "link:./libs/<package>"

@alxtz est-ce que le protocole de liens fonctionne avec les paquets en tgz?

Je pense que le protocole de liaison est la meilleure solution pour cela, file: // ne fonctionne pas car il nécessite toujours un nettoyage manuel des caches et une installation forcée

# 2165 (commentaire)

faites simplement de votre dépendance quelque chose comme ça

"<package>": "link:./libs/<package>"

Merci pour cela, cela reproduit le comportement de NPM qui créera un lien symbolique file:.. références dans node_modules . Il ne semble pas être documenté, du moins pas ici où je m'attendrais à le trouver: https://yarnpkg.com/lang/en/docs/package-json/

Malheureusement, link ne peut pas être utilisé dans tous les cas.

Par exemple, j'ai besoin d'une dépendance partagée / homologue de mon package SDK, que lorsque j'apporte des modifications, je lierai pour le travail de développement local.
Avec link , yarn ne se rend pas compte que la dépendance est une dépendance partagée / homologue et utilise le package local où se trouve le lien symbolique, ce qui est incorrect.

J'ai utilisé yarn pack aux côtés de yarn add file:<path_to_packed_tgz> pour contourner ce problème.
Bien que je puisse continuer à renommer le package à chaque fois que je l'emballe et le colle dans mon dépôt, pour ne pas générer le même hachage, comme dans @wKich fantastique trouvaille, c'est sacrément ennuyeux.

J'ai forké le repo et mis une clause supplémentaire dans l'instruction if pour empêcher yarn de charger un package local .tgz à partir de son cache s'il est spécifié en utilisant yarn add file:<path> .

const dest = this.config.getTemp(crypto.hash(url));
// If specified using file: never load from cache
if (!url.match(/file:/) && (await this.config.isValidModuleDest(dest))) {
  // load from local cache
} else {
  // continue as if it's a new package
}

Je peux faire un PR si les gens le veulent, bien que je ne l'ai jamais fait auparavant et que c'est une solution assez hacky.
Quelqu'un pourrait-il confirmer si cette approche continuerait d'ajouter les packages locaux au cache de yarn ou non, s'il vous plaît?

@ojboj pour l'instant, yalc pourrait aider jusqu'à ce que cela obtienne une solution appropriée. Cela a très bien fonctionné pour moi de tester les packages localement avant de les publier.

@souporserious C'est exactement ce dont j'avais besoin / voulu, merci beaucoup!

C'est fou, c'est toujours un problème après tant d'années.

Est-ce corrigé dans [email protected]?

@wKich je le crois! Je ne l'ai pas testé personnellement, mais il semble qu'ils résolvent le développement local grâce au nouveau protocole de portail .

J'obtiens toujours une erreur "décompresser dans la même destination" en utilisant le protocole link: , et il fait référence à mon répertoire de cache, il me semble donc que yarn met toujours en cache les dépendances link: . Je fais référence à 2 copies du même package local, copiées dans le dossier .deps/ de chaque application qui l'utilise - front-end et renderer dans l'erreur ci-dessous. (Impossible de créer un lien vers l'original pour des raisons indépendantes)

warning Pattern ["@horizon/common<strong i="11">@link</strong>:packages/front-end/.deps/@horizon/common"] is trying to unpack in the same destination "/home/garyo/.cache/yarn/v6/[email protected]/node_modules/@horizon/common" as pattern ["@horizon/common<strong i="12">@link</strong>:packages/renderer/.deps/@horizon/common"]. This could result in non-deterministic behavior, skipping.