Yarn: Les fichiers de verrouillage concurrents créent une mauvaise UX

Ajoutez la configuration à package.json pour indiquer

Cela pourrait être un bon cas d'utilisation pour le champ engine 🤔

Les allers-retours package-lock.json → yarn.lock → package-lock.json sont avec perte, mais c'est probablement sans importance. yarn.lock → package-lock.json → yarn.lock ne devrait pas être avec perte, AFAIK.

Du point de vue npm , je privilégie l'option où si yarn voit un package-lock.json et non un yarn.lock il l'importe et supprime le package-lock.json . Et de même, si npm voit un yarn.lock et non package-lock.json il devrait faire de même, en important et en supprimant le `yarn.lock.

Cela permettrait aux utilisateurs des deux outils de basculer de manière transparente dans les deux sens sans laisser le projet de l'utilisateur dans un état déroutant (où les fichiers semblent provenir des deux).

Je suis un peu préoccupé par cela, car cela signifie que ni package-lock.json ni yarn.lock ne pourront ajouter des métadonnées aux fichiers (Yarn ne le fait pas actuellement, mais pourquoi pas), en supprimant certaines liberté à nos formats dans le processus.

Ce problème soulève également la question de l'interopérabilité entre Yarn et npm en général, discutée à l'origine dans un autre fil de discussion - j'ai l'impression que d'essayer d'être trop interopérable pourrait nous mériter tous les deux, car les utilisateurs s'attendront alors à ce que tout fonctionne exactement de la même manière sur les deux projets, ce qui, à mon avis, est une hypothèse dangereuse (un exemple évident est que les espaces de travail se briseront silencieusement si quelqu'un exécute npm sur un projet alimenté par un espace de travail).

@ yarnpkg / core, des pensées?

J'aime l'idée de @ iarna de faire migrer les deux outils d'un fichier de verrouillage vers
un autre sur l'installation automatiquement.
Il est judicieux de supprimer le fichier de verrouillage importé après la migration pour éviter
les deux gestionnaires de packages concourent dans un même projet.

Les deux outils peuvent imprimer des avertissements et demander à l'utilisateur de continuer.

Je suis également d'accord avec le point de Mael selon lequel la compatibilité à 100% se verrouillera
d'explorer de nouvelles fonctionnalités, je pense que nous devrions le traiter comme un
chemin de migration, cela pourrait être une fonctionnalité plutôt petite dans install.js sur notre
côté.

Le mer.11 avril 2018 à 21:49 Maël Nison [email protected] a écrit:

Je suis un peu préoccupé par cela, car cela signifie que ni
package-lock.json ni yarn.lock ne pourront ajouter des métadonnées aux fichiers
(Yarn ne le fait pas actuellement, mais pourquoi pas), supprimant une certaine liberté à nos formats
Dans le processus.

Ce problème pose également la question de l'interopérabilité entre Yarn et
npm en général, discuté à l'origine dans un autre fil - j'ai envie d'essayer
être trop interopérable pourrait nous mériter tous les deux, car les utilisateurs
avoir l'espoir que tout fonctionnera exactement de la même manière sur les deux
projet, ce que je trouve être une hypothèse dangereuse (un exemple évident
que les espaces de travail se briseront silencieusement si quelqu'un exécute npm sur un
projet basé sur l'espace de travail).

@ yarnpkg / core https://github.com/orgs/yarnpkg/teams/core , des pensées?

-
Vous recevez cela parce que vous faites partie d'une équipe qui a été mentionnée.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/yarnpkg/yarn/issues/5654#issuecomment-380677110 , ou muet
le fil
https://github.com/notifications/unsubscribe-auth/ACBdWI9jnLJeFqH8v2T-AB74sQO1PMIjks5tntzrgaJpZM4TQ5-B
.

Pinging @imsnif car il a manifesté son intérêt pour l'implémentation de la solution "Convertir l'autre fichier de verrouillage" il y a quelques semaines. Il a peut-être même du code fonctionnel maintenant.

Merci pour le ping!

Alors oui, je suis en train de travailler exactement là-dessus. J'avais l'intention de rédiger un RFC sur le fil et d'envoyer un ping à toutes les parties prenantes la semaine prochaine.

Bref: j'ai travaillé sur la conversion de yarn.lock <==> package-lock.json. Il y a des pertes dans le processus, mais très peu d'entre elles sont logiques. À mes yeux, cela est tout à fait acceptable si nous parlons du scénario de «conversion unique» mentionné ci-dessus. Si nous souhaitons en discuter davantage, je peux entrer plus en détail.

J'ai actuellement un code rudimentaire qui fait cela: https://github.com/imsnif/synp
Ce n'est pas 100% et repose sur un dossier node_modules existant et actuel pour le projet à convertir. Je suis dans les dernières étapes d'une réécriture (sur la branche 2.0.0 ) qui obtiendra l'état du package du registre (en utilisant le génial pacote lib).

Ce que je veux faire une fois que c'est fait, c'est commencer à parler de comment (et si?) Nous aimerions implémenter cela exactement à la fois dans yarn et npm .

J'adorerais entendre les opinions de tout le monde à ce sujet.

À mes yeux, c'est tout à fait acceptable si nous parlons du scénario de `` conversion unique '' mentionné ci-dessus

Je ne pense pas que ce sera si courant. Je me trompe peut-être, mais je pense que le cas d'utilisation le plus courant sera celui des projets utilisant Yarn, et l'un des développeurs copie / colle la commande d'un README pour ajouter une dépendance, en utilisant npm au lieu de yarn dans le processus.

Dans ce contexte, je ne suis toujours pas convaincu que c'est une bonne chose de perdre des données et de modifier la mise en page du paquet en silence en essayant de faire la bonne chose - ils ne le remarqueront probablement même pas jusqu'à ce que les choses se cassent (nous pourrions avoir une invite de confirmation, mais Je m'attends à ce que les personnes qui copient / collent ces commandes confirment également aveuglément les invites d'installation). Pire encore, cela pourrait fonctionner sur leur propre machine, mais casser sur celle de leurs collègues une fois qu'ils sont revenus à Yarn.

@arcanis - Je pense que tous les scénarios et cas

Je vois cette fonctionnalité comme étant principalement utilisée dans les environnements CI, où je pense qu'elle peut briller (comme OP l'a mentionné). À tout le moins, je pense que les deux outils devraient être conscients du fichier de verrouillage de l'autre outil? Laissant les détails du moment où ils décident de faire la conversion à eux. Qu'est-ce que tu penses?

Je vois cette fonctionnalité comme étant principalement utilisée dans les environnements CI, où je pense qu'elle peut briller (comme OP l'a mentionné).

Avez-vous un exemple? Les systèmes CI sont censés agir de manière très déterministe, commettre accidentellement un fichier de verrouillage converti est quelque chose qui devrait être attrapé au pire au moment du PR imo, CI est trop tard pour cela.

À tout le moins, je pense que les deux outils devraient être conscients du fichier de verrouillage de l'autre outil?

Peut être. Utiliser la version engine pour forcer un gestionnaire de paquets spécifique me semble plus propre, les deux projets auraient juste à garder une liste de moteurs exclusifs (comme "yarn" ne peut pas être satisfait sur "npm", et inversement).

Dans mon esprit, la conversion des fichiers de verrouillage à la volée n'est pas non plus très évolutive. Par exemple, nous n'avons parlé que du fichier package-lock.json jusqu'à présent, mais je pense que pnpm a son propre fichier de verrouillage appelé shrinkwrap.yaml . Ce serait bien que nous puissions trouver un moyen de traiter les deux et tout autre format qui pourrait proposer une pierre.

Je vois cette fonctionnalité comme étant principalement utilisée dans les environnements CI, où je pense qu'elle peut briller (comme OP l'a mentionné).

Notez également que si j'ai bien compris, npm travaille actuellement sur un gestionnaire de packages très léger spécifique à CI, qui pourrait ne pas fonctionner très bien avec des choses nécessitant une logique métier lourde comme un convertisseur de fichier de verrouillage.

Concernant CI:
Ma pensée initiale était: avertir lors de l'ajout d'un nouveau package avec l'outil opposé, convertir lors d'une nouvelle installation (ou plus conservateur: échouer par défaut sur une nouvelle installation et autoriser verbeusement la conversion via une commande import ou un indicateur de configuration pour l'installation).

Lorsque je travaillais auparavant dans un environnement mixte npm / yarn, nous le faisions essentiellement manuellement avec des historiques git. C'était un processus laborieux et je suis sûr que nous étions / ne sommes pas seuls dans ce domaine.

Quant à l'évolutivité:
J'aimerais également en rendre compte.
Lorsque la conversion est effectuée, une arborescence de packages logique et physique intermédiaire (si le fichier de verrouillage en a une) est créée. Lors de la conversion vers le fichier de verrouillage souhaité, ces arbres sont utilisés (ou créés avec des valeurs par défaut saines au cas où nous convertirions à partir de yarn et que nous n'avons pas d'arbre physique).
De cette façon, nous pouvons facilement convertir entre d'autres types de fichiers de verrouillage (tout ce que nous devons faire est de fournir des conversions vers / à partir d'un arbre logique / physique pour chaque type).

C'est évidemment un peu en avance sur les capacités de l'outil actuellement, mais je ne vois pas la mise en œuvre de cela comme un gros problème.

(quant au nouvel outil ci de npm - je vois ce que vous voulez dire, mais je pense que c'est un peu en avance sur la discussion actuelle?)

ou de manière plus conservatrice: échoue par défaut lors d'une nouvelle installation et autorise la conversion verbos via une commande d'importation

Oui, je serais totalement pour ajouter cette logique de conversion dans la commande yarn import , cela semble être une fonctionnalité utile qui peut être extraite dans un package séparé si / quand nous arrivons à implémenter des plugins Yarn :) Mes commentaires sont en nous concentrant sur le comportement par défaut que nous devrions adopter.

À partir de npm@6 , vous devriez pouvoir convertir package-lock.json -> yarn.lock sans perte, sans avoir à exécuter une installation au préalable. Il doit contenir toutes les données dont vous avez besoin, les identifiants, etc. (pkglock de npm @ 6 a des plages de versions dans le champ requires , qui correspond à ce que yarn.lock utilise?)

Oh, et vous avez également besoin de https://github.com/yarnpkg/yarn/pull/5042 pour être expédié avant que cela ne soit vrai, car npm n'a pas le sha1 dans le pkglock dans de nombreux cas.

@arcanis - fantastique! Un PR avec:

1. Un avertissement lors de l'installation et de la recherche d'un fichier package-lock.json
2. Un avertissement lors de l'ajout et de la recherche d'un fichier package-lock.json
3. Ajout de la possibilité de convertir de package-lock.json via la commande import (et suppression du fichier par la suite)
   Être acceptable? (juste pour que nous ayons quelque chose que nous pouvons utiliser pour démarrer la conversation sur des détails)

@zkat - c'est super à propos de npm@6 ! Si cela dépend de moi, je choisirais de l'utiliser et de revenir aux fichiers manifestes afin de prendre en charge toutes les versions de lockfile. Puis-je vous demander si vous seriez disposé à mettre en œuvre un comportement similaire (ou peut-être quelque peu différent) pour npm ?

Notez également que si j'ai bien compris, npm travaille actuellement sur un gestionnaire de packages très léger spécifique à CI, qui pourrait ne pas fonctionner très bien avec des choses nécessitant une logique métier lourde comme un convertisseur de fichier de verrouillage.

Si par «travaille actuellement sur» vous voulez dire «ont expédié» alors oui. =)

Comme vous le suggérez, le chargement actuel de yarn.locks dépasse sa portée (car il ne sait pas comment mettre en page les arborescences de packages) mais si nous nous retrouvons tous avec une bibliothèque capable de faire cette mise en page, je ne suis pas opposé à ce qu'elle prenne en charge le chargement fil.locks. (Idéalement, ce serait une bibliothèque partagée entre lui et Yarn.) Évidemment, pour son cas, il ne devrait pas supprimer le fichier de verrouillage existant. C'est purement en lecture seule en ce qui concerne les métadonnées du package.

Un avertissement lors de l'installation et de la recherche d'un fichier package-lock.json

Je crains que le simple fait d'avoir des avertissements lorsqu'un type de fichier de verrouillage non pris en charge existe n'aidera pas les problèmes soulevés par @jmorrell que Heroku rencontre?

Je crains que le simple fait d'avoir des avertissements lorsqu'un type de fichier de verrouillage non pris en charge existe n'aidera pas les problèmes soulevés par @jmorrell que Heroku rencontre?

Un avertissement serait une amélioration, mais une erreur avec une bonne messagerie serait idéale pour les utilisateurs imo. Je ne peux parler que pour moi, mais j'ai plusieurs projets, certains qui utilisent du fil et d'autres qui utilisent npm, et je me retrouve souvent à taper le mauvais pour ce projet. Une erreur rapide signifie que je peux immédiatement utiliser celui que je devrais avoir depuis le début.

Si c'est un avertissement, il doit être important et évident. Les utilisateurs IME sont assez formés pour s'attendre à ignorer la sortie de leur gestionnaire de packages tant que cela fonctionnait.

J'ai contacté des personnes qui ont plus d'expérience avec les développeurs débutants qui, espérons-le, expliqueront à quoi ressemble cette expérience pour quelqu'un qui ne fait que commencer.

Les systèmes CI sont censés agir de manière très déterministe, commettre accidentellement un fichier de verrouillage converti est quelque chose qui devrait être attrapé au pire au moment du PR imo, CI est trop tard pour cela.

Je suis d'accord. Idéalement, au moment où elle arrive au service de build / CI, l'application n'est pas dans un état indéterminé. La seule façon dont je me sentirais à l'aise de ne pas échouer la construction dans ce cas était s'il y avait un moyen accepté pour l'utilisateur d'indiquer sa préférence dans package.json , mais cette solution impose également plus de charge à l'utilisateur.

Je crains que le simple fait d'avoir des avertissements lorsqu'un type de fichier de verrouillage non pris en charge existe n'aidera pas les problèmes soulevés par @jmorrell que Heroku rencontre?

Cela les aiderait en avertissant les utilisateurs qu'ils font quelque chose qu'ils ne veulent probablement pas avant de pousser réellement Heroku. Je ne sais pas dans quelle mesure cela changerait réellement les chiffres, mais c'est quelque chose que nous pouvons simplement vérifier dans quelques semaines et voir si nous devons aller plus loin. Et comme les changements requis sont relativement petits, cela pourrait être une bonne première itération.

Question honnête pour ceux qui proposent un avertissement: y a-t-il une situation où exécuter yarn install ou yarn add alors qu'un package-lock.json est présent ne serait npm install et yarn.lock

La migration de npm vers Yarn, ou de Yarn vers npm, vient à l'esprit. Je préfère éviter d'ajouter des frictions quand on veut essayer d'autres gestionnaires de paquets.

Une chose à garder à l'esprit est que les avertissements et les erreurs ne sont pas mutuellement exclusifs, ou du moins pas avec le champ engine . Les projets sans gestionnaires de packages épinglés peuvent imprimer un avertissement et les projets avec un gestionnaire de packages épinglé peuvent générer des erreurs. De cette façon, les utilisateurs peuvent passer librement d'un gestionnaire de paquets à l'autre, jusqu'à ce qu'ils fassent leur choix et configurent leur package.json en conséquence.

Un autre avantage du champ moteur est qu'il vous permettrait de savoir avec certitude quelle version du gestionnaire de packages doit être utilisée. Je suppose que c'est configurable quelque part, mais avec ce système, cela ferait partie du flux de travail régulier.

Un autre avantage du champ moteur est qu'il vous permettrait de savoir avec certitude quelle version du gestionnaire de packages doit être utilisée. Je suppose que c'est configurable quelque part, mais avec ce système, cela ferait partie du flux de travail régulier.

Existe-t-il un champ engine ou faites-vous référence à engines ? Je ne trouve aucun document faisant référence à engine . Toutes mes excuses si je manque quelque chose.

Nous prenons en charge la spécification de versions dans le champ engines : https://devcenter.heroku.com/articles/nodejs-support#specifying -an-npm-version

Ex:

  "engines": {
    "npm": "5.6.x"
  }

Il y a quelques soucis que j'ai avec l'utilisation de ceci pour déterminer quel gestionnaire de paquets utiliser:

• La façon dont les choses se présentent aujourd'hui: un nombre non négligeable d'utilisateurs ont à la fois npm et yarn définis, ou une version npm, mais ils ont alors un yarn.lock . Les futures versions de npm et yarn pourraient imposer cela, mais les utilisateurs qui ne mettent pas à jour fréquemment continueront à utiliser les versions actuelles pendant longtemps.

• La plupart des utilisateurs ne touchent jamais à cette configuration. Ils ont bifurqué un vieux passe-partout qui spécifiait Node 0.10 même s'ils utilisent tout ce qu'ils ont téléchargé depuis nodejs.org sur leur machine. Cela provoque un nombre non négligeable de problèmes sur Heroku.

• Les équipes ne coordonnent souvent pas les versions qu'elles ont installées. La version de Node ou de npm ou de yarn qu'ils ont installée est souvent celle qui était en cours lorsqu'ils ont démarré un projet ou la dernière fois que l'un d'eux s'est cassé et les a forcés à réinstaller. Non pas que ce soit idéal, mais je crois comprendre que la majorité des utilisateurs de npm / yarn sont des débutants, ce qui ajoute un nouvel obstacle au démarrage.

Ex: "J'ai cloné l'exemple de projet hello-world, téléchargé Node depuis https://nodejs.org , et cela n'a pas fonctionné"

Cela dit, j'aimerais , aimer, aimer si les outils imposaient des versions strictes et les enregistraient en engines . Cela éviterait de nombreuses erreurs que je vois tous les jours, mais cela ressemble à un changement beaucoup, beaucoup plus important.

Cela dit, j'aimerais, aimer, aimer si les outils imposaient des versions strictes et les enregistreraient dans les moteurs. Cela éviterait de nombreuses erreurs que je vois tous les jours, mais cela ressemble à un changement beaucoup, beaucoup plus important.

AFAIK Yarn applique ce champ strictement sauf si vous passez un drapeau pour le désactiver.

Les équipes ne coordonnent souvent pas les versions qu'elles ont installées. La version de Node ou de npm ou de yarn qu'ils ont installée est souvent celle qui était en cours lorsqu'ils ont démarré un projet ou la dernière fois que l'un d'eux s'est cassé et les a forcés à réinstaller.

Ceci est assez dangereux, en particulier lors de l'utilisation de Yarn car cela ne garantit la cohérence que sur les mêmes versions majeures de Yarn.

Non pas que ce soit idéal, mais je crois comprendre que la majorité des utilisateurs de npm / yarn sont des débutants, ce qui ajoute un nouvel obstacle au démarrage.

Que diriez-vous de Yarn (et aussi de npm, s'ils aiment l'idée) en ajoutant une entrée "yarn": "^<current_version>" dans le champ engines pour aider à introduire une certaine sécurité sans trop de friction? Nous pouvons l'ajouter automatiquement lors de l'exécution de yarn init , yarn import ou lorsque nous créons un fichier de verrouillage à partir de zéro.

Je ne sais pas grand-chose sur Yarn, mais je pense que la meilleure solution serait d'ajouter un analyseur package-lock.json dans Yarn et de ne pas créer un yarn.lock s'il existe.

Je pense que l'objectif final devrait être d'avoir un format de fichier verrou partagé entre Yarn et npm.

@thatlittlegit Vous serez alors ravi de connaître https://github.com/yarnpkg/yarn/pull/5745 . (npm fera la même chose à l'inverse, donc nous nous retrouverons dans un endroit où peu importe le type de fichier de verrouillage sur lequel vous travaillez ou l'outil que vous choisissez.)

Modifié pour ajouter: Un seul format de fichier de verrouillage n'est pas, je pense, un résultat probable car il existe différents compromis entre les formats de fichier de verrouillage et le manque de consensus sur lequel est le meilleur. Je pense qu'avoir les deux outils capables de se comprendre mutuellement est suffisant.

Au-delà de cela, il y a une tonne d'avantages à avoir plusieurs outils activement utilisés qui font des compromis différents, car cela signifie que les cas d'utilisation des utilisateurs peuvent être mieux satisfaits qu'avec une seule solution générale.

@BYK Un historique sur le comportement du champ moteur serait probablement utile ici:

Dans npm @ 1 et npm @ 2 , nous avions un package.json appelé engineStrict en plus des champs engine . Si engineStrict était vrai, alors le champ du moteur était utilisé comme _résolution contrainte_ et avant d'appliquer la plage semver à la liste des versions, les versions avec des moteurs incompatibles seraient filtrées. Cela vous permettrait de faire des choses comme npm install foo et d'obtenir [email protected] même si [email protected] était publié si [email protected] n'était pas pris en charge sur votre plate-forme. Cela _semble_ souhaitable, mais en pratique était très déroutant, en particulier parce que les documents sur le site Web ne concernaient que la version la plus récente.

Si engineStrict était faux, la résolution était effectuée sans tenir compte des champs du moteur et des avertissements étaient émis si le résultat n'était pas compatible.

Il y avait AUSSI une option de configuration engine-strict , qui faisait la même chose que la propriété package.json , mais l'appliquait à TOUS les packages.

À partir de npm @ 3 , nous avons abandonné la prise en charge de la propriété engineStrict package.json et changé le comportement de l'option engine-strict config. L'option de configuration transforme désormais les avertissements que vous obtenez avec elle en erreurs, mais n'affecte pas la résolution.

Les champs engine sont appliqués non seulement pour le projet de niveau supérieur, mais de manière transitoire. L'introduction d'un indicateur de moteur yarn impliquerait que les dépendances ne peuvent être installées qu'avec yarn et je ne pense pas que ce soit le cas ici.

Puisque dans la prochaine version de yarn nous devrions avoir la possibilité d'importer package-lock.json vers yarn.lock - j'aimerais revenir sur le problème des avertissements / erreurs.

La façon dont je le vois: je ne pense pas qu'il y ait une bonne raison pour qu'un seul paquet ait à la fois un fichier package-lock.json et un fichier yarn.lock . La plupart des projets que j'ai vus qui ont cela le considèrent sciemment comme un problème qui doit être résolu plutôt que comme une situation souhaitée (mais je suis bien sûr ouvert à la correction).
Comme je le comprends d' après l'explication de engine ne sera pas une bonne solution pour spécifier explicitement le gestionnaire de packages qu'un package utilise.
Donc, l'OMI, c'est une situation qui devrait produire une erreur verbeuse qui inviterait l'utilisateur à supprimer un fichier ou à le convertir.

Cependant, je pense que produire une telle erreur serait un changement radical. Du côté du fil, je proposerais de commencer par un avertissement (comme mentionné ci-dessus) et de déprécier lentement ce comportement jusqu'à la prochaine version majeure dans laquelle il serait changé en erreur (peut-être en ajoutant un indicateur de configuration qui permettrait aux deux fichiers de existent simultanément).

Que pense tout le monde? @jmorrell , @BYK , @arcanis , @iarna?

Il me semble étrange que tout type de projet spécifie quel outil de gestion de paquet doit être utilisé. Corrigez-moi si je me trompe, mais je vois Yarn comme un remplacement instantané qui dépend principalement des préférences de l'utilisateur final. Yarn tente-t-il de remplacer entièrement le NPM en tant que norme de facto, ou tente-t-il de coexister?

@BrainBacon Vous n'obtenez les avantages des dépendances verrouillées que si tout le monde utilise le même gestionnaire de paquets qui respecte le même fichier de verrouillage et utilise la même sémantique. Si un projet a un yarn.lock et que quelqu'un exécute alors un npm install , cette personne peut toujours se retrouver avec un ensemble différent de dépendances. Donc non, cela ne dépend malheureusement pas des préférences de l'utilisateur final - de préférence, tout le monde sur un projet utilise le même gestionnaire de packages.

Cela signifie également qu'il n'a pas de sens d'avoir deux fichiers verrouillés dans un projet. Il est peu probable qu'ils se résolvent à la même arborescence de dépendances et ne permettent pas aux contributeurs de savoir quel gestionnaire de packages utiliser.

(Le remplacement de la pièce de rechange était particulièrement vrai lorsque npm ne produisait pas de fichiers de verrouillage, car il n'y avait aucune information à perdre. C'est également toujours vrai si # 5745 signifie vraiment que Yarn peut maintenant produire un fichier de verrouillage basé sur package-lock.json , mais cela signifie seulement qu'un _projet_ peut alors facilement remplacer npm par Yarn. Cependant, comme vous devez toujours archiver le nouveau fichier de verrouillage, tous les contributeurs devront changer.)

Corrigez-moi si je me trompe, mais je vois Yarn comme un remplacement instantané qui dépend principalement des préférences de l'utilisateur final.

Yarn n'est pas un remplacement direct en termes d'API exposée. Le yarn add <pkg> vs npm install <pkg> est un exemple évident de quelque chose où nous faisons les choses différemment. Nous avons tendance à avoir le même ensemble de fonctionnalités, mais à la fin, ce sont deux outils différents et parfois nous avons des solutions différentes à un même problème.

Le yarn.lock vs package-lock.json est l'une de ces différences et je pense que ni Yarn ni npm ne sont intéressés à en utiliser un seul, car ils contiennent des informations différentes.

Du côté du fil, je proposerais de commencer par un avertissement (comme mentionné ci-dessus)

Je serais bien avec ça. Quelque chose comme:

WARN Your project seem to contain lock files (package-lock.json, shrinkwrap.json) generated
WARN by other tools than Yarn. It is advised not to mix package managers, in order to avoid
WARN resolution inconsistencies caused by desynchronized lock files.

Quelqu'un veut-il ouvrir un PR?

Je serais heureux d'ouvrir un PR qui ajoute un avertissement :)

La solution finale souhaitée est-elle ici une erreur utile lorsque package-lock.json existe + yarn import ? Ma compréhension était que @iarna préconisait que chaque outil supprime / convertisse le fichier de verrouillage opposé s'il existe automatiquement.

L'une ou l'autre solution serait une amélioration significative pour les utilisateurs, mais je pense qu'il serait préférable que yarn et npm choisissent la même stratégie (bien que ce ne soit pas strictement nécessaire s'il n'y a pas d'accord et que les gens sont convaincus).

@jmorrell - je crois comprendre que nous avons convenu que la conversion automatique est une mauvaise idée ici.

Principalement parce qu'il est difficile de savoir quel devrait être le delta entre les deux fichiers de verrouillage.
Par exemple. quand je vois l'avertissement ci-dessus en tant que développeur, ce que je voudrais probablement faire est de déterminer quand l'autre lockfile a été créé, quels paquets y ont été ajoutés qui n'ont pas été ajoutés à mon lockfile principal, puis les ajouter. Peut-être utiliser l'option import comme référence, mais pas nécessairement.

J'espère que les gens de npm sont d'accord sur celui-ci?

Idéalement, j'aimerais que l'avertissement comprenne quelque chose à propos de cette situation obsolète (je ne suis pas sûr du libellé) et que les futures versions de fil produiront une erreur. Peut-être un lien vers une documentation détaillée à ce sujet et comment y remédier. @arcanis - pensez-vous que c'est faisable, ou préférez-vous rester avec le comportement warning ?

Si les deux outils émettent un error lorsqu'il y a plusieurs fichiers verrouillés, je pense que les développeurs comprendront ce problème tant qu'il est encore «petit» et pourront le résoudre rapidement (avec l'aide de l'importation comme référence ou sans) .

@arcanis npm add <pkg> est parfaitement valide et fait ce que Yarn fait 👼

En ce qui concerne pkglock vs yarnlock, l'intention initiale de package-lock.json était de créer un format qui incluait toutes les données dont le gestionnaire de paquets avait besoin. En fait, pkglock à partir de npm@6 peut être converti de manière transparente en un yarn.lock sans exécuter un programme d'installation, car il décrit une arborescence complète avec toutes les métadonnées pertinentes. Nous l'avons fait _intentionnellement_ (comme le champ requires ), et nous avons demandé des commentaires aux équipes Yarn et pnpm pour nous assurer que tout ce que nous avons fait était suffisant pour que les deux puissent l'utiliser comme fichier de verrouillage importable ou comme alternative. yarn.lock est, malheureusement, un sous-ensemble avec perte, donc l'inverse n'est pas vrai, mais nous ajouterons quand même des éléments pour l'importer. npm obéirait même aux formes d'arbres calculées par Yarn (contrairement à Yarn, qui ne le ferait pas).

En fait, pkglock à partir de npm @ 6 peut être converti de manière transparente en un yarn.lock sans exécuter un programme d'installation, car il décrit une arborescence complète avec toutes les métadonnées pertinentes.

Je ne pense pas que ce soit possible (mais peut-être que je me trompe, n'hésitez pas à signaler toute idée fausse). Le fichier de verrouillage Yarn ne prend pas en charge, par conception, plusieurs gammes de résolution en une seule version. Si vous avez plusieurs packages chacun en fonction de lodash@^1.0.0 , ils utiliseront tous exactement la même version. Ce n'est pas seulement une optimisation, mais aussi la façon dont nous encodons les choses dans notre fichier de verrouillage.

Le fichier de verrouillage npm étant un arbre, cette propriété n'est pas garantie et plusieurs plages identiques peuvent finir par utiliser des versions différentes (ce qui est bien, car cela pourrait permettre des optimisations légèrement meilleures en exploitant les règles de résolution de nœud). Dans de telles circonstances, la conversion package-lock.json -> yarn.lock serait avec perte, car nous n'aurions pas d'autre choix que de les fusionner en un seul.

D'un autre côté, un fichier de verrouillage Yarn peut être transformé en package-lock.json relativement sans problème, car nos règles sont un sous-ensemble plus strict de la vôtre (nos plages fusionnées peuvent être transformées en un arbre sans perte, un arbre ne peut pas être transformé en une plage fusionnée sans perte). Notez que je ne parle que de l'arborescence de dépendances elle-même, je ne suis pas familier avec vos champs de métadonnées.

Pour être honnête, je ne suis pas tout à fait sûr que nous disions la même chose ou quelque chose de complètement différent, je voulais juste clarifier un peu la situation 🙂

Idéalement, j'aimerais que l'avertissement comprenne quelque chose à propos de cette situation obsolète (je ne suis pas sûr du libellé) et que les futures versions de fil produiront une erreur. Peut-être un lien vers une documentation détaillée à ce sujet et comment y remédier.

@imsnif Je ne suis pas convaincu que ce soit une erreur dans les environnements non-CI (pas de question sur CI - c'est quelque chose qui devrait certainement déclencher une erreur). Je préférerais rester sur un avertissement qui décrit simplement l'état actuel et explique pourquoi ce n'est pas idéal.

Une bonne chose est que @jmorrell sera en mesure de nous fournir des métriques précises pour voir si l'avertissement a été suffisant, et sur cette base, nous choisirons notre prochain coup.

La solution finale souhaitée est-elle ici une erreur utile lorsque package-lock.json existe + importation de fil?

Oui, couplé au mode "upgrade-to-error-on-CI" * Je pense que c'est une première étape raisonnable!

(* Cela n'existe pas encore, je le mentionnerai dans le # 5773 Yarn 2.0 WG)

@arcanis - À propos de lockfiles: Je pense que ce à quoi @zkat fait référence (mais s'il vous plaît @zkat corrigez-moi si je me trompe ou si j'ai mal compris) c'est que package-lock.json sauve l'arbre physique et logique, tandis que yarn.lock sauvegarde uniquement l'arborescence logique. Ainsi, comme mentionné précédemment, la conversion de package-lock.json => yarn.lock => package-lock.json perdra les données de l'arbre physique. IMO dans la plupart des cas, c'est bien, mais il y a des exceptions: par exemple. dépendances groupées.

Mon opinion personnelle est que les deux gestionnaires de packages peuvent bénéficier de la synchronisation de leur construction d'un arbre physique. De ce que j'ai vu, nous pouvons probablement extraire des règles bien définies sur la façon dont un arbre physique est créé et les deux les suivre (idéalement avec un module maintenu par tous les intervenants). Je pense que cela résoudra à la fois le problème de compatibilité, certains problèmes que yarn a avec les dépendances groupées, tout en permettant à chaque gestionnaire de paquets de conserver ses particularités uniques. (Bien que je reconnaisse que je suis assez nouveau dans cette discussion, il peut donc y avoir des choses dont je ne suis pas au courant - mes excuses si je réveille des chiens endormis).

Pour le problème en question cependant: @arcanis - Je vais essayer de proposer juste un argument de plus ici en faveur des erreurs générales dans cette situation, et si vous n'êtes pas d'accord, nous pouvons rester avec les avertissements en ce qui me concerne:
Bien qu'il soit en effet assez important que cela soit pris au niveau du CI, je pense qu'une erreur serait beaucoup plus difficile à déboguer (en moyenne) qu'une erreur dans l'environnement local du développeur.
Si un développeur obtient une erreur sur son environnement local pour avoir utilisé le mauvais outil, il n'ira probablement pas plus loin. Ils disaient simplement "oups" et utilisaient l'autre outil. Cela économisera énormément de temps, au lieu de l'attraper sur le CI après avoir développé une fonctionnalité, puis revenir en arrière.
Un avertissement (comme cela a été mentionné précédemment ici) peut être englouti dans de nombreux autres que les développeurs ont tendance à ignorer si le statut de sortie est 0.
Qu'est-ce que tu penses?

De plus, dans la situation que j'ai décrite ci-dessus, le fichier de verrouillage "étranger" peut être placé dans .gitignore et ainsi le CI n'aura même pas la chance de le savoir. En tant que développeur distrait, je pourrais penser "Eh bien, cela me donne un avertissement obscur sur mon environnement local, mais cela passe CI - donc c'est probablement juste un problème local de mon côté - ah bien"

Un avertissement (comme cela a été mentionné précédemment ici) peut être englouti dans de nombreux autres que les développeurs ont tendance à ignorer si le statut de sortie est 0.

Mon point est que cette affirmation n'est étayée par aucune donnée, même si nous avons un moyen d'en collecter pour ensuite prendre une décision éclairée. Dans ce contexte, le choix de l'option plus radicale qui va briser le flux de travail des peuples me semble futile de peu et potentiellement dangereux 😕

De plus, je pense que vous oubliez un peu la user story de "J'utilise un gestionnaire de paquets et je veux en essayer un autre", ce qui, à mon avis, est assez important pour toutes les personnes impliquées, aussi bien pour les mainteneurs que pour les utilisateurs. Ce ne serait pas génial si les gens ne pouvaient pas facilement essayer npm 6 de leur projet Yarn (ou inversement, essayer Yarn de leur projet npm).

Mon opinion personnelle est que les deux gestionnaires de packages peuvent bénéficier de la synchronisation de leur construction d'un arbre physique.

C'est un sujet différent, mais je ne suis pas d'accord. Je pense qu'il y a une idée fausse selon laquelle Yarn est npm, ce qui est incorrect. Si vous souhaitez importer un projet dans un autre via une commande dédiée, je suis tout à fait pour, mais la conversion (ou la lecture) silencieuse de fichiers de verrouillage à partir d'un format tiers est une recette pour un désastre:

• il ignorera les fichiers de configuration
• cela cassera l'arborescence physique la prochaine fois qu'un package sera ajouté / supprimé
• toute fonctionnalité propre à un gestionnaire de packages ne fonctionnera pas (espaces de travail, remplacement de résolution, lien :, ...)

Mon point est que cette affirmation n'est étayée par aucune donnée, même si nous avons un moyen d'en collecter pour ensuite prendre une décision éclairée. Dans ce contexte, choisir l'option la plus radicale qui brisera le flux de travail des gens me semble un peu futile et potentiellement nuisible confus

Vrai - il n'est soutenu par aucune donnée. Je spécule définitivement ici (désolé si je n'ai pas souligné cela). Bien que nous puissions avoir une idée de la tendance du correctif d'avertissement, nous ne serons pas en mesure de comprendre à quel point cela est pratique pour les utilisateurs et s'il existe une solution plus pratique. Si nous nous basons sur les données, je ne pense pas qu'il y ait d'autre résultat que "il n'y a eu absolument aucun changement dans le taux d'erreur de déploiement Heroku" qui nous orientera vers la solution d'erreur globale.

Je conviens qu'il est très important de ne pas interrompre les flux de travail des gens. C'est pourquoi j'ai proposé l'erreur comme un changement radical dans 2.0.0 , avec un libellé dans l'avertissement qui alerterait l'utilisateur que cette situation est obsolète. Je pense également que nous pouvons autoriser l'utilisation d'un paramètre --force ou config pour remplacer ce comportement. (Je pense que cela répond également à votre tentative d'essayer l'autre problème du gestionnaire de paquets?)

C'est un sujet différent, mais je ne suis pas d'accord. Je pense qu'il y a une idée fausse selon laquelle Yarn est npm, ce qui est incorrect. Si vous souhaitez importer un projet dans un autre via une commande dédiée, je suis tout à fait pour, mais la conversion (ou la lecture) silencieuse de fichiers de verrouillage à partir d'un format tiers est une recette pour le désastre

Je pense que vous soulevez ici des préoccupations importantes que j'aimerais aborder. Mais comme vous le dites, c'est un sujet différent et je ne veux pas faire dérailler la conversation. Peut-être pouvons-nous en discuter dans un autre numéro?

Je pense que la conversation ici a un peu déraillé, alors je veux la ranger avec quelques clarifications et un résumé:

1. Yarn et npm ont des stratégies de résolution et de création d'arbres physiques différentes et c'est un facteur clé pour que les deux projets existent.
2. Les fichiers yarn.lock et package-lock.json ont été créés avec des objectifs spécifiques à l'esprit et pour autant que je sache, ces objectifs ne s'alignent pas complètement mais se chevauchent.
3. La différence entre ces objectifs ne rend pas un format supérieur aux autres en général, ils font juste des compromis.

Sur cette base, je pense que conserver les deux formats est en fait essentiel pour l'innovation et pour répondre à des besoins différents. Ce qu'il faut, c'est assurer la portabilité du projet avec une perte de données minimale entre les gestionnaires de paquets sans imposer une stratégie particulière de gestionnaires de paquets à l'autre pour permettre une expérimentation gratuite.

Je vois la reconnaissance et l'avertissement contre d'autres fichiers de verrouillage ainsi qu'une conversion appropriée avec un message clair sur ce qui est conservé et ce qui est perdu comme une grande valeur pour les utilisateurs de chaque côté. Alors maintenant, la question ici dans ce numéro est de savoir quel est le meilleur flux pour les utilisateurs qui ont un fichier de verrouillage de package dans leur dépôt lorsqu'ils exécutent yarn .

On dirait que la conversion automatique est potentiellement dangereuse et qu'une installation échouée sans issue peut blesser certaines personnes. Que diriez-vous d'exiger qu'une configuration soit définie pour yarn pour savoir que le fait d'avoir un fichier de verrouillage de package est prévu en mode CI? Ceci est un signal des développeurs au fil, disant "Je sais ce que je fais donc n'essayez pas de me protéger contre toute discordance".

Pensées?

Que diriez-vous d'exiger qu'une configuration soit définie pour yarn pour savoir que le fait d'avoir un fichier de verrouillage de package est prévu en mode CI? Ceci est un signal des développeurs au fil, disant "Je sais ce que je fais donc n'essayez pas de me protéger contre toute discordance".

@BYK - @arcanis m'a convaincu ici et sur discorde, il pourrait être bon d'ajouter également un avertissement en mode non-ci lorsque l'indicateur de configuration n'est pas défini. Pour que les développeurs aient une chance de savoir que leur build CI pourrait échouer avant de pousser (et aussi de se protéger contre package-lock.json étant dans .gitignore ).

@arcanis comme @imsnif l'a mentionné: pkglock inclut _les deux_ la disposition logique et physique de l'arbre. En suivant la version logique de l'arborescence (qui comprend les plages dont nous avons dédoublé), vous pouvez créer un yarn.lock en mémoire sans aucune installation ni exécution de logique d'installation. Juste des recherches d'arbre :)

À partir des notes de publication de NPM 5:

Une nouvelle fonctionnalité de fichier de verrouillage standardisée destinée à la compatibilité entre les gestionnaires de packages (package-lock.json)

Il semble que l'équipe NPM annonce package-lock.json comme la solution universelle; est-il (techniquement) possible de rejoindre cette force?

Une solution que j'aimerais proposer serait "d'utiliser seulement package-lock.json quand il existe déjà". C'est en gros ainsi que NPM a "migré" du film rétractable vers un fichier lock json.

Il semble que l'équipe NPM annonce package-lock.json comme la solution universelle; est-il (techniquement) possible de rejoindre cette force?

Nous en avons déjà discuté, veuillez vérifier le reste du fil si vous ne l'avez pas fait. Cela ne se produira pas à court terme.

Je pense que vous oubliez un peu la user story de "J'utilise un gestionnaire de packages et je veux en essayer un autre", ce qui, à mon avis, est assez important pour toutes les personnes impliquées

Ce n'est probablement pas une chose fréquente, le changement de contexte. J'ai choisi Yarn il y a quelque temps et je n'ai pas regardé en arrière. Je pense qu'il vaut mieux mettre un peu de poids derrière la raison pour laquelle les fichiers de verrouillage sont là. Faites-en une erreur qui peut être désactivée, plutôt qu'un avertissement qui sera ignoré. Quand quelqu'un valide un fichier de verrouillage, c'est pour une raison.

Nos statistiques montrent que la majorité des utilisateurs de Yarn utilisent également npm. Les _projets_ mixtes sont rares, mais une seule personne travaillant sur plusieurs projets, dont certains sont npm et certains sont Yarn, est assez courant. Pour compliquer davantage le problème, installer des scripts qui exécutent directement npm est une chose.

Je veux utiliser du fil, mais la plupart des projets sur lesquels je travaille n'ont que des fichiers package-lock.json . Je ne peux pas ajouter yarn.lock fichiers yarn import est lent et / ou cassé. Actuellement mon
L'option _only_ est d'abandonner le fil et de passer à npm.

Je comprends que le fil est fabriqué par des développeurs de fil uniquement pour des projets de fil uniquement. Mais qu'en est-il du reste d'entre nous?

Hey @Spongman - yarn import ne devrait pas être cassé. Il devrait maintenant pouvoir importer package-lock.json pour vous. Si vous rencontrez des problèmes, veuillez nous en informer!

J'ai fait # 6103

Hey @Spongman - J'ai commenté dans le problème, ce cas spécifique était dû à un package-lock.json corrompu. Je serais heureux de connaître tous les autres problèmes.

npm peut utiliser ce fichier package-lock.json très bien. le fil doit être plus résistant.

A répondu à cela dans l'autre numéro - je demande que la discussion se déplace là afin de garder cette question sur le sujet. Merci!

Je regardais attentivement et participais à https://github.com/yarnpkg/yarn/issues/3614 (avec actuellement 254: +1: s). Cette question est maintenant close et la discussion est déplacée ici.

En ignorant les défis pratiques, à mon avis, le meilleur UX serait de loin fourni par une option non mentionnée dans le résumé en haut, mais mentionnée par @thatlittlegit :

Je pense que l'objectif final devrait être d'avoir un format de fichier verrou partagé entre Yarn et npm.

Ce qui est également soutenu par le point de @BrainBacon :

Il me semble étrange que tout type de projet spécifie quel outil de gestion de paquet doit être utilisé.

Encore une fois, en ignorant les défis pratiques pendant une minute, le contre-argument théorique à cela a été fait par @iarna dans ce fil (et @jhabidas dans l'autre fil ):

Il y a une tonne d'avantages à avoir plusieurs outils activement utilisés qui font des compromis différents, car cela signifie que les cas d'utilisation des utilisateurs peuvent être mieux satisfaits qu'avec une seule solution générale.

Personnellement, je ne pense pas que cet argument devrait s'appliquer dans ce cas, comme je l'ai fait dans un commentaire sur l'autre fil (avec 95: +1: s, 2: -1: s):

Oui je suis d'accord, Yarn veut conserver son espace indépendant autant que possible, donc il a la flexibilité de fournir une meilleure expérience. C'est pourquoi, par exemple, la CLI de Yarn n'est délibérément pas compatible avec les NPM.

Cependant, je pense que les fichiers de verrouillage sont en dehors de l'espace où Yarn peut raisonnablement maintenir son indépendance. package-lock.json et composer.lock sont engagés dans le référentiel , aux côtés de package.json et composer.json . Il ne s'agit pas de fichiers spécifiques à un outil, mais plutôt de fichiers spécifiques au projet spécifiant les versions de dépendances exactes avec lesquelles le projet est garanti de fonctionner.

...

Pour que Yarn soit un outil utile, il doit permettre aux développeurs de suivre des modèles standard dans leurs projets, afin que le projet puisse rester indépendant des outils. Ce qui, après tout, est pourquoi Yarn a été construit sur package.json et non sur son propre fichier de dépendances séparé.

Après avoir lu la plupart de ce fil, je suis toujours d'accord avec mon évaluation initiale - si Yarn continue à consommer le même fichier de dépendance package.json du référentiel, idéalement, il devrait émettre le même fichier package-lock.json dans le référentiel , de sorte que le référentiel peut rester indépendant des outils. Si Yarn lisait ses dépendances depuis yarn.json au lieu de package.json je ne continuerais pas à faire valoir ce point.

Je pense que nous devons admettre que c'est la situation idéale , l'expérience utilisateur transparente. Cependant, je comprends l'autre point de @iarna :

Un seul format de fichier verrouillé n'est pas, je pense, un résultat probable car il existe différents compromis entre les formats de fichier verrouillé et l'absence de consensus sur lequel est le meilleur.

(bien que je ne sois pas d'accord sur le fait que "avoir les deux outils capables de se comprendre mutuellement est suffisant").

Si le scénario idéal de permettre aux référentiels d'être indépendants des outils n'est certainement pas réalisable (et je vois les nombreux commentaires sur la façon dont les différents fichiers de verrouillage sont construits de manières fondamentalement différentes et contiennent des informations différentes), alors où nous semblons aller semble à peu près acceptable, ce qui est:

• NPM / Yarn émettra des avertissements s'ils repèrent le fichier de verrouillage de l'autre (et peut-être une option de configuration pour en faire une erreur)
• Les deux outils fournissent des mécanismes pour convertir un fichier de verrouillage en un autre

Je ne pense pas que l'un ou l'autre devrait, en aucun cas, convertir et supprimer le fichier de verrouillage de l'autre. Cela signifierait que les nouveaux développeurs passeraient pour toujours de l'un à l'autre et inversement, en fonction de l'outil utilisé par le développeur (étant donné que trop de personnes s'engagent avec git commit -a ).

Je ne suis pas non plus d'accord avec le point de vue de

Je ne pense pas qu'il y ait une bonne raison pour qu'un seul package ait à la fois un fichier package-lock.json et un fichier yarn.lock.

Je pense qu'il est présomptueux de dicter ce qu'un développeur exécute sur son ordinateur ou dans son environnement de production. Il est au moins courtois de ne pas être plus restrictif que nécessaire. Si votre projet n'est jamais géré que par votre équipe de développeurs et qu'ils ont tous exactement le même logiciel en cours d'exécution, tant mieux. Mais vous pouvez avoir un développeur qui trouve qu'il est beaucoup plus facile d'utiliser NPM que Yarn pour une raison quelconque. Et surtout si vous créez un logiciel open source, vous voulez que les membres de la communauté soient aussi faciles à démarrer que possible. Étant donné que NPM et Yarn sont simplement des outils pour installer les mêmes dépendances à partir de package.json , ils devraient simplement fonctionner. Un développeur devrait être capable de voir package.json , avoir un outil pour l'interpréter et ne pas avoir à s'inquiéter davantage. Ce qui était le cas avant que ce conflit de fichiers de verrouillage ne survienne seul.

Salut @nottrobin - Je pense que je comprends d'où tu viens. Si nous ignorons les défis pratiques et les différences philosophiques, il serait certainement préférable pour les utilisateurs des différents outils qu'ils consomment tous le même fichier de verrouillage (c'est mon opinion personnelle, bien sûr).

Mais comme nous ne pouvons pas ignorer les défis pratiques et semblant généralement convenir que les différences philosophiques ont leur place, je pense que le compromis auquel nous sommes parvenus (celui que vous avez décrit ci-dessus) est définitivement "assez bon".

Notez qu'une hypothèse cachée dans ledit compromis est que le choix de l'outil est fait par projet plutôt que par machine ou environnement de production du développeur.

Notez qu'une hypothèse cachée dans ledit compromis est que le choix de l'outil est fait par projet plutôt que par machine ou environnement de production du développeur.

Oui, je pense que c'est ce qui me préoccupe le plus - même si je pense que dans le scénario que j'ai décrit ci-dessus, il est toujours possible d'avoir un projet soutenant à la fois Yarn et NPM.

Je pense qu'en fin de compte, si les deux projets abandonnent la mission d'essayer de permettre à un projet d'être indépendant des outils, ils devraient vraiment arrêter de partager un fichier de dépendance. Yarn doit passer en lecture yarn.json plutôt que package.json . Tout le reste est juste désordonné et déroutant.

Si npm lockfiles a déjà un sur-ensemble des relations de dépendance prises en charge par Yarn lockfiles, pourquoi ne pas prendre en charge les deux dans Yarn? Yarn pourrait basculer vers package.json et tous les champs supplémentaires souhaités par Yarn pourraient être ajoutés à l'avenir (de la même manière que certains éditeurs SVG comme Inkscape gèrent les métadonnées de l'éditeur). Ensuite, Yarn pourrait avoir le même format de dépendance que npm et être rétrocompatible avec yarn.lock, convertissant les fichiers de verrouillage npm en la structure que Yarn veut en mémoire avec perte.

Je pense qu'en fin de compte, si les deux projets abandonnent la mission d'essayer de permettre à un projet d'être indépendant des outils, ils devraient vraiment arrêter de partager un fichier de dépendance. Yarn doit passer en lecture yarn.json plutôt que package.json . Tout le reste est juste désordonné et déroutant.

Peut-être, peut-être pas. Certes, cela nécessiterait un changement de rupture massif de l'outil (fil). Des changements moins radicaux avec des avantages plus directs et mesurables ont été ignorés.

Je ne dis pas que c'est une mauvaise idée, je dis simplement que je ne pense pas que ce soit pratique.

Je ne dis pas que c'est une mauvaise idée, je dis simplement que je ne pense pas que ce soit pratique.

Je conviens que cela semble être une grande demande. Mais ce que je dis, c'est que cela semble être une question cruciale pour le projet.

Jusqu'à présent, Yarn était un outil que les développeurs pouvaient choisir d'utiliser à la place de NPM pour installer les dépendances Node pour tout projet avec un package.json . Maintenant, comme vous le faites remarquer, cela oblige les projets à choisir explicitement entre Yarn et NPM. C'est un énorme changement, et ne devrait pas être fait accidentellement. C'est le point crucial pour faire cet appel.

À mon avis, il y a 3 façons d'avancer:

1. Continuez à remplacer NPM en trouvant un moyen d'aligner Yarn avec NPM sur toutes les interfaces au niveau du projet (normaliser le fichier de verrouillage)
2. Déviez délibérément de NPM en utilisant explicitement des interfaces au niveau du projet différentes (par exemple yarn.json et yarn.lock )
3. Doubler en fournissant la moitié de l'interface NPM et une interface à moitié différente. C'est en fait la même chose que le point 2., mais tout en regardant la plupart des gens comme le point 1.

Je pense que la troisième option confond ici tout l'espace Node et affaiblit considérablement les deux outils.

Il peut toujours être rétrocompatible. Yarn pourrait simplement avoir un convertisseur npm lockfile intégré, donc quand il verra package-lock.json, il le conservera et le convertira au format de yarn.lock en mémoire. Autant que je sache, npm ne peut pas faire cela car le fichier de verrouillage de Yarn contient moins d'informations que celui de npm, donc à mon avis, il serait préférable que Yarn se standardise avec npm.

@nottrobin Je pense que vous avez généralement raison dans votre analyse, cependant:

Maintenant, comme vous le faites remarquer, cela oblige les projets à choisir explicitement entre Yarn et NPM. C'est un énorme changement, et ne devrait pas être fait accidentellement.

Je pense que cela a toujours été le cas, ou du moins pour le principal avantage que Yarn était initialement censé apporter: la reproductibilité des arbres de dépendance. Vous pouvez enregistrer votre yarn.lock , mais cela est pratiquement inutile si d'autres développeurs ajoutent / suppriment des dépendances sans respecter ce fichier de verrouillage.

@nottrobin - Je suis d'accord avec @Vinnl. Comme je l'ai mentionné ci-dessus, même si je ne veux pas être en mesure de dire à qui que ce soit comment ils devraient fonctionner, je pense que l'utilisation à la fois de fil et de npm pour installer des dépendances dans le même projet est un anti-modèle.

Même si les deux outils pourraient techniquement faire beaucoup de travail pour que cela fonctionne, je ne pense pas que ce soit quelque chose que nous, les responsables de la maintenance, devrions encourager. Il y a d'innombrables autres avantages à avoir des fichiers de verrouillage interchangeables (comme le montrent les différentes discussions dans les différents fils) mais je ne pense pas que ce soit l'un d'entre eux, personnellement.

mais c'est pratiquement inutile si d'autres développeurs ajoutent / suppriment des dépendances sans respecter ce fichier de verrouillage.

Oui, je suppose que dans une certaine mesure, Yarn était dans cette eau boueuse depuis le début - l'existence de yarn.lock signifiait déjà qu'il avait en partie sa propre interface. Je pense que c'était toujours une chose un peu compliquée à faire, qui servait l'objectif de Yarn de vouloir que les gens passent du NPM à Yarn, mais pas en arrière.

Mais c'était une décision que je me sentais plus à l'aise de prendre pour mon projet, car au moins je savais que NPM était toujours entièrement pris en charge - comme il ne fournissait pas de verrouillage en premier lieu, il continuerait à fonctionner aussi bien qu'il l'a toujours fait.

Maintenant, cela a changé, car NPM verrouille les dépendances. Si je choisis de lier un projet à Yarn, je garderai maintenant yarn.lock à jour, et non package-lock.json , il n'est donc plus vrai que quelqu'un puisse utiliser NPM efficacement sur mon projet.

On dirait que vous dites que le fil n'est plus destiné à remplacer directement le npm? Qu'il n'est censé être utilisé que par des projets de fil uniquement?

Je pense que si c'est le cas, alors vous devez à tout le monde de préciser ce fait sur la page d'accueil du fil - utilisez ceci ou npm, pas les deux.

On dirait que vous dites que le fil n'est plus destiné à remplacer directement le npm?

Cela ne l’a jamais été. L'interface a quelque peu imité npm pour que les utilisateurs comprennent plus facilement comment l'utiliser, mais depuis le tout début, certaines choses ont fonctionné différemment. La principale raison pour laquelle certaines personnes pensaient qu'il s'agissait d'un remplacement instantané était que npm manquait simplement de fonctionnalités pour comparer.

Maintenant que npm rattrape certains aspects et décide de mettre en œuvre les choses différemment, cela commence simplement à montrer que nous avons différentes approches et que nous prenons des décisions différentes (par exemple, la récente fonctionnalité de miroir hors ligne implémentée npm n'est pas compatible avec la nôtre). Donc en bref: ça n'a jamais été "sûr", c'est juste arrivé à travailler accidentellement.

Je pense que si c'est le cas, alors vous devez à tout le monde de préciser ce fait sur la page d'accueil du fil - utilisez ceci ou npm, pas les deux.

En fait, nous avons des instructions de migration . Votre remarque m'a fait remarquer qu'il contient malheureusement un mauvais paragraphe qui pourrait donner aux gens une mauvaise impression 🙁 Nous accepterions volontiers qu'un PR change ce paragraphe en quelque chose de plus conforme à nos recommandations (c.-à-d. Utiliser Yarn de manière cohérente entre les équipes, dans l'ordre pour que chacun puisse bénéficier des différentes fonctionnalités susceptibles d'être utilisées par le projet).

Ça n'a jamais été

euh ... vous devez alors parler à vos responsables marketing. https://yarnpkg.com/lang/en/docs/

Yarn interagit directement avec de nombreuses fonctionnalités de npm, y compris son format de métadonnées de package, permettant une migration sans douleur.

Nous n'avons pas de spécialistes du marketing, mais nous acceptons les bons RP 🙃

Dans ce cas particulier, cela ne semble pas trop faux. Nous interagissons avec de nombreuses fonctionnalités, mais pas avec toutes, et la migration est indolore dans la plupart des cas (au pire, c'est à yarn import ).

la migration est indolore

je ne suis pas vraiment intéressé par la migration. Je cherche ce qui a été promis ici (ces gars ont _defini_ des gens du marketing): https://code.fb.com/web/yarn-a-new-package-manager-for-javascript/

Il dispose du même ensemble de fonctionnalités que les flux de travail existants tout en fonctionnant plus rapidement, de manière plus sûre et plus fiable.

le fil aujourd'hui n'est pas ça.

AFAICT il y a 4 classes d'utilisateurs ici:

• ceux qui utilisent uniquement du fil dans leurs projets,
• ceux qui ont acheté l'argumentaire de vente de facbook (ci-dessus) mais qui n'ont encore rencontré aucun de ces problèmes de verrouillage,
• ceux qui essaient péniblement de contourner les incompatibilités en convertissant manuellement les fichiers de verrouillage si nécessaire, ou en utilisant d'autres hacks pour le faire fonctionner,
• ceux qui ont juste abandonné le fil et sont revenus à npm.

Je ne veux vraiment pas être dans la dernière catégorie, mais il semble que c'est là que je suis poussé.

@Spongman, qu'est-ce qui vous empêche de ce dernier? Nous pouvons probablement le réparer;)

@Spongman Je ne suis pas affilié à Yarn, donc je suppose que je peux être un peu plus direct: il est vraiment inutile de dire dans ce numéro que vous pensez que le libellé est faux. Si vous pensez que le libellé est incorrect, accédez à cette page dans GitHub, cliquez sur le bouton Modifier et soumettez une demande d'extraction avec une meilleure formulation. arcanis a clairement indiqué ci-dessus qu'ils étaient ouverts à cela.

(Je suppose que vous ne pouvez probablement pas modifier l'article du blog, mais le site Web est probablement le plus important ici.)

Je peux voir d'après les réponses de @arcanis que la position officielle ici semble être que Yarn n'a "jamais eu l'intention" de continuer à travailler de manière transparente aux côtés de NPM.

Mais je suis totalement d'accord avec @Spongman pour

Dans les deux cas, ce problème rend la position de Yarn à ce sujet beaucoup plus claire pour moi qu'elle ne l'était auparavant, et bien sûr, les responsables de Yarn peuvent choisir de prendre la direction de leur choix.

Mais je pense que vous sous-estimez considérablement le nombre de personnes qui ont utilisé Yarn précisément parce qu'ils pensaient qu'il maintenait la compatibilité avec NPM (au niveau du projet), et n'auraient jamais fait le changement autrement. Je crois que les 254: +1: s et 10: heart: s sur https://github.com/yarnpkg/yarn/issues/3614 et les 57 votes positifs sur " Devrais-je commettre yarn.lock et package-lock.json fichiers? », cela est très clair.

Si Yarn abdique toute responsabilité sur ce front, je pense qu'il perdra non seulement @Spongman et mes équipes, mais bien d'autres encore.

Franchement, je ne comprends vraiment pas le problème que vous rencontrez en utilisant uniquement Yarn, ou seulement npm. Ce que vous dites est en gros "hé, je ne peux pas forcer mon équipe à utiliser Yarn, donc je vais les forcer à utiliser npm". Cela n'a aucun sens pour moi. Si vous utilisez les fonctionnalités de Yarn, faites en sorte que tout le monde utilise Yarn, et si vous souhaitez utiliser les fonctionnalités de npm, faites en sorte que tout le monde utilise npm. C'est aussi simple que ça.

Tout entre les deux signifie qu'au moins vos builds ne sont pas cohérents dans toute votre équipe, ce qui va à l'encontre du principe de Yarn, comme mentionné précédemment. Un de vos ingénieurs pourrait commencer à utiliser les espaces de travail, et cela fonctionnerait, mais s'arrêterait sur npm. Idem pour le miroir hors ligne. Idem pour les résolutions de dépendance. Pire encore, puisque certains champs sont entièrement inconnus de npm, cela ferait silencieusement la mauvaise chose.

En ce qui concerne la communication, l'article du blog fb ne mentionne pas de remplacement instantané. Permettez-moi de citer la partie où Yarn est introduit. Il dit littéralement qu'il remplace le flux de travail. Je suppose que vous avez été confus par le "reste compatible avec le registre npm", ce qui est un bon point que vous devriez apporter à npm, pas à nous (il y a le npm cli, le registre npm, et bien sûr npm Inc lui-même).

Yarn est un nouveau gestionnaire de packages qui remplace le flux de travail existant pour le client npm ou d'autres gestionnaires de packages tout en restant compatible avec le registre npm.

qu'est-ce qui vous empêche de ce dernier? Nous pouvons probablement le réparer;)

@zkat C'est utile, merci.

@nottrobin - Je ne peux pas parler des intentions originales de Yarn parce que je n'étais pas là à l'époque. Je travaillais cependant dans un environnement mixte fil / npm avec plusieurs dizaines de référentiels.

Je peux dire qu'il était parfaitement clair pour tous les développeurs impliqués à l'époque que le choix du fil / npm était un choix par repo, tout comme le choix de express / hapi, mobx / redux, etc. Cela est devenu encore plus clair avec npm @ 5 est sorti avec son propre format de fichier de verrouillage et certains développeurs ont décidé de commencer à l'utiliser avec de nouveaux référentiels.

Lorsqu'un développeur installait une dépendance avec le mauvais outil, cela créerait un désordre avant même npm @ 5 , car cette dépendance ne serait pas systématiquement verrouillée. Cela a causé des problèmes dans nos différents environnements et il était très clair pour toutes les personnes impliquées que c'était une erreur *.

Je me rends compte que cela peut être déroutant - et je comprends que cela peut ne pas être clair à 100% pour tout le monde sans aucune faute de leur part, mais je ne pense pas qu'il soit juste de changer radicalement l'outil pour s'adapter à ce malentendu. À mon avis, le fil est une baisse de remplacement pour npm sur une base par repo plutôt que par boîte.

* Certes, cette situation particulière de plusieurs dépôts sans espace de travail avec un outillage mixte fil / npm n'était pas idéale au niveau humain plutôt qu'au niveau technique pour exactement ces potentiels d'erreur et elle a finalement été corrigée. J'utilise cet exemple ici pour montrer que les deux outils peuvent fonctionner côte à côte s'ils sont approchés correctement.

Franchement, je ne comprends vraiment pas le problème que vous rencontrez en utilisant uniquement Yarn, ou seulement npm.

Oui, vous @arcanis et @imsnif avez clairement indiqué que vous ne comprenez pas. Le seul point que je veux dire, c'est que beaucoup de gens (regardez le: +1: s) ont fait la même «erreur» et veulent que Yarn travaille aux côtés de NPM, que vous compreniez cela ou non. Si Yarn n'est pas l'outil pour nous, qu'il en soit ainsi.

(Juste un dernier point - @imsnsi c'est complètement ridicule de comparer un outil pour installer des dépendances Node à un choix de projet comme express vs hapi, mobx vs redux. Ce sont des caractéristiques fondamentales de votre application. Si vous ne pouvez pas voir la différence évidente, Pas étonnant que vous ne compreniez pas mon point.)

Bref, j'ai fini maintenant. Je pense avoir fait valoir mon argument du mieux que je peux.

Pour les projets open source, il n'est jamais question de forcer "l'équipe" à utiliser du fil ou du npm. Il s'agit de savoir ce qui convient le mieux à tout le monde. Dans le monde réel, npm est roi, donc, à moins que le fil ne puisse jouer bien dans un monde npm, il est mort.

^ Ceci

Je crains que ce soit également une idée fausse. Au cours de l'année écoulée, Yarn est passé de 20% du montant total des demandes au registre npm à 40% en avril . La dernière fois que j'ai entendu les statistiques (directement des gens de npm, puisque nos statistiques ont récemment cassé lorsque le registre npm est allé à Cloudflare), c'était environ 48% des demandes. Dans le monde réel réel, Yarn et npm coexistent, clairement et simplement.

J'apprécierais maintenant si nous pouvions revenir au sujet en question, à savoir: qui est prêt à écrire un PR pour écrire un avertissement lorsque nous détectons un fichier package-lock.json au moment de l'installation? Merci.

Psst, @arcanis - https://github.com/yarnpkg/yarn/pull/5920

Génial: heart_eyes:

Entre cela et votre travail sur yarn import , pouvons-nous alors résoudre ce problème?

Je pensais que nous attendrions que

EDIT: afaik l'avertissement n'a pas encore été publié, il nous reste donc encore du temps à attendre.

Je crains que ce soit également une idée fausse.

Comment? Le volume de trafic chez npm ne vous dit rien sur l'open source ou non du projet.

une évaluation plus précise serait de compter quels projets github ont 0,1 ou 2 de (yarn.lock, package-lock.json). personnellement, je n'ai jamais vu un projet open-source (de toute taille appréciable) sur github qui a un fichier yarn.lock et _no_ package-lock.json (sauf l'évidence).

Si vous souhaitez conserver des fichiers de verrouillage séparés, les DEUX gestionnaires de paquets doivent détecter le fichier de verrouillage et l'ERREUR de l'autre (éventuellement avec un indicateur de remplacement).

Tous - Je vous demanderais de bien vouloir rester sur le sujet et de mettre hors ligne tous les commentaires non directement liés (par exemple, notre chaîne Discord). Il y a beaucoup de gens abonnés à ce fil et, pour être honnête, je pense que la discussion npm <> yarn n'a pas sa place ici. Merci!

Je n'ai pas lu toute la bande de roulement, mais l'utilisateur IHMO doit au moins être averti qu'il y a une ambiguïté:

si npm voit un fichier yarn.lock, alors npm devrait afficher quelque chose comme:
"AVERTISSEMENT: ce projet semble utiliser yarn, vous devriez peut-être utiliser 'yarn' au lieu de 'npm install'"

si yarn voit le fichier package-lock.json, alors yarn devrait afficher quelque chose comme:
"ATTENTION: ce projet semble utiliser npm, vous devriez peut-être utiliser 'npm install' au lieu de 'yarn'"

Et comme suggéré ci-dessus, un moyen de "préférer" le gestionnaire de paquets (dans package.json).

Je peux dire qu'il était parfaitement clair pour tous les développeurs impliqués à l'époque que le choix du fil / npm était un choix par repo, tout comme le choix de express / hapi, mobx / redux, etc.

Ce n'était pas du tout clair pour moi. Jusqu'à présent, je pensais que c'était un choix local pour les développeurs, et plusieurs développeurs pouvaient coexister sur un seul dépôt en utilisant celui qu'ils aimaient, alors qu'il était _un peu plus pratique_ d'en utiliser un seul de manière cohérente. Les exemples express / hapi, etc. sont bons cependant et indiquent clairement que ce n'est pas un choix. Cela devrait avoir plus de visibilité.

Ajoutez un champ dans package.json pour indiquer quel gestionnaire de packages un projet doit utiliser

"package-manager": "yarn"

Je pense que c'est la meilleure solution, si elle est implémentée dans tous les gestionnaires de paquets.

Les gestionnaires de paquets DOIVENT alors refuser à 100% de continuer s'ils sont appelés sur le mauvais projet, tout comme vous vous attendriez à une erreur si vous aviez besoin de redux mais que vous essayiez d'appeler des fonctions mobx dessus. Ils doivent émettre une erreur, pas un avertissement, et informer l'utilisateur comment procéder avec le gestionnaire de packages approprié.

Ajoutez un champ dans package.json pour indiquer quel gestionnaire de packages un projet doit utiliser
"package-manager": "yarn"

Je pense que c'est la meilleure solution, si elle est implémentée dans tous les gestionnaires de paquets.

Si vous voulez que npm tienne compte de cela, je vous encourage à ouvrir une discussion dans le lieu approprié , mais je dirai que je n'aime pas cette direction. Je voudrais voir une convergence entre les gestionnaires de paquets et non une divergence.

Je recommanderais de ne pas utiliser de nouveau champ "package-manager", en recommandant plutôt la strophe engines existante qui a déjà de l'art antérieur.

Les documents yarn et npm mentionnent (en passant) l'utilisation de engines.npm et engines.yarn pour spécifier les versions de chacun qui devraient être utilisées. Yarn produira même une erreur si la version de fil ne satisfait pas engines.yarn .

https://yarnpkg.com/en/docs/package-json#engines -
https://docs.npmjs.com/files/package.json#engines

Même si ni npm ni yarn ne vérifient engines pour le manager "concurrent" (ce qui serait bien), utiliser ce champ reste un excellent moyen de communiquer aux autres développeurs quel manager est censé être utilisé. (si l'existence de package-lock.json ou yarn.lock ne suffit pas pour indiquer)

Je voudrais voir une convergence entre les gestionnaires de paquets et non une divergence.

D'accord. Soit convergence, soit refus.

mais le compromis ambigu et erroné actuel est nuisible.

Je pense toujours que le simple fait de lancer une erreur en présence du fichier de verrouillage des autres nécessiterait le moins de friction pour les projets existants.

Si vous souhaitez que npm en tienne compte, je vous encourage à ouvrir une discussion dans le lieu approprié

Merci, je viens de m'inscrire. Il y a un fil récent dans ce sens: https://npm.community/t/npm-install-should-warn-about-the-presence-of-yarn-lock-files/1822

Mon vote est pour l'erreur de point final au lieu de simplement avertir, donc je ne sais pas si je devrais ajouter à ce fil de discussion pour en démarrer un nouveau.

Je voudrais voir une convergence entre les gestionnaires de paquets et non une divergence.

Pareil ici. Bien qu'ils soient incompatibles pour le moment, la divergence s'est déjà produite et cause déjà des frictions à de nombreux utilisateurs et projets.

Quelle que soit la convergence issue des discussions ultérieures entre les équipes, cela prendra du temps. Quand cela arrive, les erreurs proposées peuvent être levées et les utilisateurs peuvent commencer à changer et à mélanger les gestionnaires de paquets sans un jeu d'enfant.

L'ajout des erreurs évite désormais davantage de confusion et n'interrompt pas les efforts dans le sens de la convergence.

Je recommanderais de ne pas utiliser de nouveau champ "package-manager", en recommandant plutôt la strophe des moteurs existants qui a déjà l'art antérieur.

Cela semble raisonnable. Je ne suis attaché à aucune méthode particulière de détection de la présence d'un gestionnaire de paquets incompatible.

Pour ajouter une illustration, mon cas d'utilisation en particulier est gatsbyjs. La situation est exactement la même que celle rapportée par @gaearon ici :

Pour créer les utilisateurs de l'application React, cela est extrêmement déroutant car leur projet est créé avec Yarn (si Yarn existe sur le système), mais ils suivent ensuite la documentation d'une bibliothèque qui leur dit d'installer npm install, et cela épuise tout l'arbre.

Pour éviter ce problème, même si gatsby utilise du fil, il ajoute également un package-lock.json aux démarreurs par défaut . Mais les utilisateurs se retrouvent avec les deux fichiers de verrouillage et commencent à voir des avertissements. Il est facile de supprimer simplement l'un d'entre eux, mais cela embrouille l'expérience d'intégration.

Merci à tous pour votre contribution.

@jmorrell - https://github.com/yarnpkg/yarn/pull/5920 est sorti en 1.9.2 le 25 juillet. Cela fait un peu plus d'un mois, je sais que ce n'est pas beaucoup de temps (et sûrement pas tout le monde s'est mis à jour) - mais avez-vous peut-être des idées à partager concernant les erreurs de double verrouillage sur Heroku depuis lors?

@imsnif Merci pour le rappel par e-mail! Désolé d'avoir manqué la mise à jour ici.

Voici un graphique du nombre d'applications qui ont connu cet échec particulier chaque semaine en 2018.

(J'ai rédigé l'échelle y, mais cela représente des centaines de développeurs et montre la tendance)

1. La baisse de juillet provient d'un problème sans rapport avec S3

2. En regardant la tendance après le 25 juillet, l'avertissement semble avoir eu un effet substantiel sur le nombre de personnes ayant subi cette erreur. Je suis quelque peu surpris par l'ampleur du changement.

@jmorrell - c'est vraiment super!
J'avoue que je suis également assez surpris de cela.

Je pense (du côté du fil) que ce problème peut être considéré comme résolu. Êtes-vous d'accord?

Je pense toujours que le conseil de supprimer package-lock.json pour corriger l'erreur est trompeur - cela entraînera généralement l'utilisation d'un ensemble différent de versions de package et conduira (encore une fois, en général) à des incompatibilités et des ruptures. De plus, ces conseils ne sont utiles que pour ceux qui prennent des décisions sur le gestionnaire de paquets qu'un projet utilise. les contributeurs généraux qui suivent ces conseils vont également rencontrer des problèmes.

IMO si un package-lock.json existe et que yarn ne peut pas garantir que les versions qu'il installe sont les mêmes que celles que npm installerait, alors il devrait échouer avec une erreur .

Merci encore pour votre contribution @Spongman. Je pense que tout cela a été bien discuté dans le (très long) fil de discussion ci-dessus et je ne pense pas qu'il soit logique de le redémarrer. Je pense que nous comprenons tous votre position. Merci d'avoir participé.

À moins que @jmorrell ne me dise le contraire dans la semaine prochaine, je vais considérer cela comme fait et clore ce problème.

@imsnif En prenant une piste différente et en examinant les échecs de septembre jusqu'à présent (1er septembre au 20 septembre), c'est toujours la principale raison pour laquelle Node construit sur Heroku échoue. Cela se produit deux fois plus que le prochain cas d'échec connu le plus courant: package.json étant un JSON invalide. Encore une fois, en supprimant les chiffres exacts, voici comment cela se compare à d'autres problèmes.

Je n'ai vu aucun mouvement de npm à ce sujet, alors je vais créer un PR en ajoutant un avertissement là aussi et voir qu'il est accepté.

Je pense (du côté du fil) que ce problème peut être considéré comme résolu. Êtes-vous d'accord?

Je ne pense pas que cela ait été résolu pour les utilisateurs, et l'expérience utilisateur n'est toujours pas excellente. Mais je peux voir comment les chiffres changent une fois que npm donne également des commentaires à un utilisateur qui rencontre ce cas.

Je vous laisse décider si vous souhaitez fermer ceci ou apporter d'autres modifications. Je suis heureux d'ouvrir un nouveau numéro dans quelques mois si cela reste un gros problème pour les utilisateurs.

@jmorrell - vu que ce problème attire beaucoup d'attention et que la conversation ne cesse de recommencer et même de se répéter, je pense qu'il serait préférable de la clôturer maintenant avec les informations dont nous disposons.

Si, avec npm fournissant également un avertissement, nous voyons toujours un problème, je serais certainement prêt à recommencer la discussion sur l'erreur (ou à rechercher d'autres solutions). S'il vous plaît, faites-moi un ping personnellement dans ce cas.

Merci d'avoir soulevé cela, contribué et réalisé tous ces changements! Personnellement, je pense que le fil est meilleur après ce problème.