basé sur le blog de laine :

Lorsque vous publiez un package qui contient un fil.lock, aucun utilisateur de cette bibliothèque n'en sera affecté. Lorsque vous installez des dépendances dans votre application ou bibliothèque, seul votre propre fichier fil.lock est respecté. Les fichiers de verrouillage dans vos dépendances seront ignorés.

il ne semble pas nécessaire de regrouper wire.lock lors de la publication du package individuel... il s'agit plutôt d'un artefact de développement pour l'ensemble du référentiel, il n'est donc pas nécessaire de le mettre dans chaque package.

@connectdotz, il n'est peut-être pas nécessaire pour une bibliothèque ou un package publié, mais pour créer un conteneur Docker, vous voudrez le déployer quelque part, ce serait certainement le cas.

bien sûr ... mais le conteneur docker de développement n'aurait-il pas tout le dépôt et donc le fil.lock de toute façon? Je peux voir que nous utilisons des conteneurs docker pour tester notre projet monorepo pour différents systèmes d'exploitation ou plates-formes, auquel cas nous déployons simplement l'ensemble du référentiel et son fil.lock. Pouvez-vous me donner un exemple de cas d'utilisation dont vous avez besoin pour déployer des packages individuels du projet monorepo dans des conteneurs Docker pendant le cycle de développement, afin que je puisse avoir une compréhension plus concrète...

Donc, pour nous, nous ne voulons pas empaqueter l'ensemble du monorepo dans le conteneur docker résultant. Nous utilisons docker en production et ces images doivent être aussi claires que possible. Notre dépôt mono est assez volumineux et contient plusieurs microservices qui partagent du code entre eux à l'aide de packages de bibliothèque (et certaines bibliothèques sont pertinentes pour certains microservices, mais pas tous). Ainsi, lorsque nous empaquetons un microservice, nous voulons que l'image contienne les fichiers de ce microservice et toutes les autres dépendances en tant que dépendances appropriées - téléchargées à partir de notre registre privé et créées pour l'arche de l'image docker.

Je pense donc que la principale considération ici est de garder nos images de docker aussi légères que possible, et l'emballage de l'ensemble du monorepo ne correspond pas à nos besoins. De plus, lorsque nous exécutons "yarn" à l'intérieur de l'image du microservice, nous ne voulons pas y avoir de liens symboliques, juste une dépendance normale.

La solution ici n'a pas besoin de créer un fichier fil.lock par espace de travail, il peut également s'agir d'une commande fil, qui aide au processus d'empaquetage d'un espace de travail donné, générant un fichier fil.lock pour un espace de travail à la demande, etc. ..

J'espère que cela a aidé à clarifier le cas d'utilisation .. 🍻

@netanelgilad merci pour les détails, cela aide à clarifier que votre cas d'utilisation concerne davantage la publication de packages individuels, pour la production ou le développement, dans des conteneurs docker. Veuillez vous joindre à la discussion au #4521 afin que nous puissions commencer à les consolider.

Bien que je puisse voir l'utilisation de fichiers de verrouillage individuels, ils ne sont pas nécessaires. Si vous exécutez docker à partir de la racine du référentiel avec l'indicateur -f pointant vers les fichiers individuels, vous aurez le référentiel entier comme contexte et pourrez copier dans le package.json et le fil.lock à partir de la racine.

Vous n'avez besoin que du package.json pour les packages que vous allez créer dans l'image et fil n'installera que les packages pour les fichiers package.json que vous avez copiés, même si le fil.lock comprend beaucoup plus.

EDIT : Cela dit. cela empêche l'utilisation du cache docker pour les modifications de package dans un package, même s'il n'est pas inclus dans la construction

4206 est lié/en double, et le cas d'utilisation décrit ici est exactement le problème auquel nous sommes confrontés :

Disons que nous avons dix packages différents. Nous voulons qu'ils vivent tous dans leur propre référentiel afin que les gens puissent travailler dessus de manière indépendante s'ils le souhaitent, mais nous voulons également pouvoir les relier entre eux si nous en avons besoin. Pour ce faire, nous avons un méga référentiel avec un sous-module pour chaque package, et un package.json qui référence chacun de ces sous-modules en tant qu'espace de travail.

J'ai des problèmes similaires avec les espaces de travail. Mon projet est un web-app qui dépend de nombreux packages locaux :

web-app/
|--node_modules/
|--packages/
|  |--controls/
|  |  |--src/
|  |  |--package.json
|  |--utils/
|     |--src/
|     |--package.json
|--src/
|--package.json
|--yarn.lock

Les packages d'espace de travail controls et utils ne sont pas publiés et sont utilisés par les chemins. Le problème est que je dois publier le package controls ( yarn pack ) et je ne veux pas le construire/tester tout seul. Cela signifie que je veux faire yarn install intérieur de web-app/packages/constols/ . Avec les espaces de travail, il utilisera le fichier de niveau supérieur web-app/yarn.lock fichier de niveau supérieur web-app/node-modules/ . Ainsi, il installe tous les packages au lieu d'un sous-ensemble, spécifié dans web-app/packages/controls/package.json . Mais je dois vérifier que mon package a toutes les dépendances requises dans ses propres package.json et ne fonctionne pas par chance de remplir les deps manquants d'autres espaces de travail.

Il y a 2 solutions possibles :

1. S'il n'est pas root, utilisez le yarn.lock root, mais installez uniquement les packages spécifiés dans le package.json local.
2. Ne recherchez pas les configurations de niveau supérieur, mais .yarnrc/.npmrc .

Aussi aux prises avec cela. Nous avons un projet Angular CLI à côté de notre API, ils sont donc dans le même référentiel et essaient de pousser le frontend vers Heroku.

Nous utilisons un pack de construction qui indique à Heroku de passer d'abord au référentiel frontal : https://github.com/lstoll/heroku-buildpack-monorepo

Le problème est qu'il n'y a pas de yarn.lock intérieur de ce package nohoist donc Heroku s'installe simplement avec npm et nous nous retrouvons avec tous les nouveaux packages plutôt que ceux verrouillés

Vous pouvez simplement utiliser le fichier fil.lock global avec les packages individuels. J'ai récemment approché mon Dockerfile comme ceci :

WORKDIR /app
ENV NODE_ENV=production

ADD yarn.lock /app/
ADD package.json /app/

# Only copy the packages that I need
ADD packages/my-first-package /app/packages/my-first-package
ADD packages/my-second-package /app/packages/my-second-package

RUN cd /app && yarn install --frozen-lockfile

Cela n'installera que les dépendances réellement utilisées par les deux packages que j'ai copiés et par personne d'autre.

J'ai un processus de construction où j'aimerais d'abord créer un artefact de version à partir d'un package, puis aucune de ses dépendances n'est installée. C'est assez facile avec la construction en plusieurs étapes de Docker

1. Ajoutez uniquement fil.lock, package.json et le package d'interface utilisateur à docker
2. courir yarn install --frozen-lockfile
3. exécuter le processus de construction
4. démarrez une nouvelle étape et ajoutez fil.lock, package.json et les packages d'exécution/dossiers d'espace de travail nécessaires
5. Faites un COPY --from=<stage> pour l'artefact construit
6. exécutez yarn install --frozen-lockfile et exposez une commande RUN .

Et vous vous retrouverez avec un petit conteneur qui ne contient que les dépendances spécifiées dans votre fichier fil.lock et nécessaires à la production.

@johannes-scharlach
J'ai fini par utiliser une méthode presque identique à ce que vous décrivez. la construction en plusieurs étapes est un bon conseil :).

@connectdotz Je pense que de mon côté, ce problème pourrait être clos et nous pouvons continuer à travailler sur le problème #4521. Étant donné que le fichier fil.lock principal pourrait fonctionner avec un sous-ensemble des packages, il semble qu'un fil.lock par espace de travail n'est pas nécessaire (même si je pense toujours que cela pourrait être un meilleur workflow de développement 😉 ). Mais le problème dans # 4521 est toujours important, car dans la solution à laquelle nous sommes arrivés ici, nous devons mentionner chaque espace de travail de dépendance dans le Dockerfile même si fil doit connaître les interdépendances et comment "fournisseur" un espace de travail donné.

J'ai passé les deux derniers jours à essayer de convertir notre monorepo en espaces de travail Lerna puis Yarn. Le fil a fonctionné généralement de manière plus fiable et il est vraiment proche de ce dont nous avons besoin, en particulier avec l'introduction récente de yarn workspaces run <script> et d'autres bonnes choses comme wsrun .

Cependant, le single yarn.lock est un problème :

• Je ne sais pas comment migrer correctement nos fichiers de verrouillage existants vers un seul, voir https://github.com/yarnpkg/yarn/issues/6563. Nous y avons des dizaines de milliers de lignes et l'ajout de packages existants en tant qu'espaces de travail a introduit de nombreux problèmes subtils de version.
• L'installation de dépendances dans un package spécifique uniquement ("de-hoisting" / "vendoring") La construction dockerisée n'est pas bien prise en charge, voir ci-dessus (https://github.com/yarnpkg/yarn/issues/5428#issuecomment-403722271) ou https : //github.com/yarnpkg/yarn/issues/4521.

Que penseriez-vous du fait que les espaces de travail Yarn ne soient qu'un petit noyau - une déclaration de packages sans aucune fonctionnalité spécifique. Par exemple:

• Si vous vouliez exécuter un script dans vos espaces de travail, vous feriez yarn workspaces run <script> .
• Si vous vouliez un seul fichier de verrouillage et de levage (les deux sont-ils forcément liés ensemble ?), ce serait votre racine package.json :
  json "workspaces": { "packages": ["packages/*"], "hoistDependencies": true }
• Si vous vouliez migrer vos fichiers de verrouillage actuels vers une structure hissée, vous exécuteriez yarn workspaces hoist-dependencies .

Etc. Ce ne sont que des exemples et dans la pratique, certaines fonctionnalités seraient probablement désactivées au lieu d'être activées (par exemple, les gens s'attendent à un seul yarn.lock et à un levage maintenant) mais l'idée générale est que les espaces de travail être une base légère pour les tâches à l'échelle du dépôt.

Qu'est-ce que tu penses?

Je pense que le problème auquel cette demande de fonctionnalité répond est le même que dans #4521 . Une commande pour faire essentiellement ce que @johannes-scharlach décrit serait certainement plus faisable qu'un fichier de verrouillage par espace de travail.

Il existe également une RFC ouverte en ce moment pour les espaces de travail imbriqués , ce qui ressemble à cette demande de fonctionnalité, bien que je pense que cela résout un problème différent.

Que penseriez-vous des espaces de travail Yarn n'étant qu'un petit noyau - une déclaration de packages sans aucune fonctionnalité spécifique

Les espaces de travail ne changeront pas radicalement, je pense que nous sommes satisfaits de leur interface actuelle.

Si vous vouliez exécuter un script dans vos espaces de travail, vous feriez yarn workspaces run <script>

C'est déjà possible (v1.10, #6244).

Si vous vouliez migrer vos fichiers de verrouillage actuels vers une structure hissée, vous exécuteriez yarn workspaces hoist-dependencies .

Puisque nous ne changerons pas l'interface de l'espace de travail, ce serait le contraire ( dehoistDependencies ).

Ce que je n'aime pas à ce sujet, c'est qu'il prend un comportement technique (levage) et essaie de le transformer en un comportement sémantique. Vous devez vous concentrer sur l'histoire de l'utilisateur, puis comprendre la mise en œuvre plutôt que l'inverse.

Dans ce cas, je pense que votre cas d'utilisation ("Installation de dépendances dans un package spécifique uniquement") serait mieux résolu en étendant yarn --focus .

Je suppose que la question centrale est de savoir si le levage et un seul fichier yarn.lock sont strictement nécessaires pour les espaces de travail. Je veux dire, est-ce que ce qui les définit vraiment ou est-ce "juste" la première caractéristique qu'ils ont historiquement?

Par exemple, dans notre cas d'utilisation, le meilleur comportement hypothétique des espaces de travail serait :

• Levez node_modules au moment du développement pour plus d'efficacité.
• Conservez les fichiers yarn.lock locaux pour la construction (nous construisons des packages spécifiques dans Docker, ce que d'autres personnes ont également mentionné dans ce fil) et également pour que les packages puissent verrouiller leurs versions spécifiques. Voir aussi #6563.
• Exécutez des scripts via yarn workspaces run <script> même si vous n'avez pas besoin (ou devez éviter) de levage.

Le levage peut être désactivé avec nohoist , run peut être "désactivé" en n'utilisant tout simplement pas la commande mais il n'est pas possible de "désactiver" le seul fichier yarn.lock , et I' Je ne sais pas si c'est une fonctionnalité si essentielle qu'elle ne peut pas être désactivée ou si elle n'a tout simplement pas encore été suffisamment demandée :)

Je pense que la meilleure façon de résoudre ce problème serait d'avoir yarn install --app-mode package@version

De cette façon, vous pouvez simplement copier les fichiers de verrouillage de l'espace de travail lors de la publication de votre application à une certaine version, et l'installation dans app-mode respectera le fichier de verrouillage fourni.

Yarn n'a pas besoin d'installer l'intégralité du fichier de verrouillage ; il devrait être facilement capable d'extraire uniquement la partie du graphe de dépendances correspondant à ce package.

En fait, cela pourrait être assez facile à faire manuellement même maintenant :

• téléchargez le package zip directement depuis le registre (le fil n'a pas d'équivalent, npm le fait : npm pack package@version )
• extraire le gzip dans node_modules/package
• cd dans node_modules/package
• exécutez fil install --production à partir de là (il respectera le fichier de verrouillage fourni)

edit : malheureusement, tout est faux, car le fichier de verrouillage de l'espace de travail n'inclut pas les versions des packages dans l'espace de travail, qui peuvent être des dépendances du package de l'application. Il faudrait quelque chose de plus impliqué que la copie lors de la création de fichiers de verrouillage d'application à partir de fichiers de verrouillage d'espace de travail.

Je ne sais pas exactement si des fichiers de verrouillage séparés sont la réponse, mais j'ai un problème similaire. J'ai configuré un monorepo avec une CLI et un backend. La CLI nécessite quelques packages spécifiques à la plate-forme et ne fonctionne que sur les ordinateurs de bureau avec une configuration particulière. D'un autre côté, j'ai besoin de pouvoir construire mon api dans une image docker, ce qui est fondamentalement impossible dans l'implémentation actuelle des espaces de travail.

Cas d'utilisation très similaire à celui de @samuela ici ! Celui-ci serait extrêmement utile!

Mon cas d'utilisation peut sembler risible par rapport aux autres, "vrais". Mais j'ai un monorepo pour certains utilitaires - dans ce cas, des crochets de réaction - à l'intérieur de packages/* .

J'ai un deuxième espace de travail à côté de packages/* , et c'est local/* . C'est en fait sur gitignore, et l'idée est que les développeurs de l'entreprise peuvent y faire ce qu'ils veulent, par exemple y mettre des applications create-react-app et tester les crochets pendant le développement.

Maintenant, bien que les packages local/* soient sur gitignore, la racine yarn.lock est simplement gonflée et polluée - et vérifiée dans git - à cause des espaces de travail locaux.

Ce que je souhaiterais, c'est un moyen de spécifier que certains espaces de travail doivent utiliser des fichiers de verrouillage spécifiques, par exemple un mappage comme ceci :

  "workspaces": {
    "packages": [
      "packages/*",
      "local/*"
    ],
    "lockfiles": {
      "local/*": "./local.yarn.lock"
    }
  }

Ou même un moyen de spécifier "ne rien mettre du tout de _ce_ espace de travail dans le fichier de verrouillage".

Mais oui, le mien n'est pas un cas d'utilisation sérieux en premier lieu :)

Je ne sais pas exactement si des fichiers de verrouillage séparés sont la réponse, mais j'ai un problème similaire. J'ai configuré un monorepo avec une CLI et un backend. La CLI nécessite quelques packages spécifiques à la plate-forme et ne fonctionne que sur les ordinateurs de bureau avec une configuration particulière. D'un autre côté, j'ai besoin de pouvoir construire mon api dans une image docker, ce qui est fondamentalement impossible dans l'implémentation actuelle des espaces de travail.

Vous l'avez compris - à mon avis, l'un des principaux avantages du fichier fil.lock est de créer des versions de production gelées ! Les créateurs de Yarn l'ont-ils oublié ?

Un autre argument pour résoudre le problème du fichier de verrouillage unique est la propriété du code. Si vous avez un monorepo qui utilise quelque chose comme la fonctionnalité GitHub CODEOWNERS, il n'est pas possible de donner la propriété complète d'un package à un groupe de développeurs. C'est parce que s'ils installent quelque chose dans leur propre espace de travail, ils changeront invariablement le fichier de verrouillage au niveau racine. Ce changement devra être approuvé par les propriétaires de code du fichier de verrouillage, qui, étant donné un monorepo d'une échelle suffisante, sera différent des propriétaires de l'espace de travail d'origine.

Encore une autre raison d'avoir une option pour générer des fichiers de verrouillage par espace de travail : Google App Engine refuse de lancer un service Node sans fichier de verrouillage (NPM/Yarn). C'est d'excellents devops de leur part, mais une douleur pour nous. Jusqu'à présent, les options que nous avons sont:

• Déployez tout avec env vars indiquant de quel service nous parlons et modifiez notre yarn start (le seul point d'entrée pris en charge) pour créer une branche basée sur env vars
• Demandez au script de construction de copier le fichier de verrouillage principal dans chaque espace de travail et de déployer uniquement le service qui nous intéresse. (merci @johannes-scharlach)

En fin de compte, je pense qu'une commande yarn install --workspace-lockfile qui génère des fichiers de verrouillage par espace de travail serait la meilleure solution.

Avoir une option pour les fichiers de verrouillage au niveau du package nous aiderait également. Notre cas d'utilisation est un peu différent, nous testons une nouvelle façon de gérer les dépendances locales.

Nous avons donc déjà des dépôts mono, et nous avons des dépôts qui ne contiennent qu'un seul package. Ceux-ci sont tous publiés et peuvent donc être utilisés ensemble, mais il arrive souvent que les avoir localement et liés symboliquement soit très utile.

Mais certains développeurs ont du mal à gérer les liens symboliques, etc. Nous essayons donc un référentiel mono d'espace de travail de fil vide standard que nous clonons tous sur nos machines, puis nous clonerons les référentiels de packages dans ce référentiel mono local. Certains d'entre nous n'ont peut-être qu'un seul clone de paquet, d'autres en ont 5. C'est très pratique et fait du développement local, inter-repo, inter-dépendance un jeu d'enfant.

Mais nous avons rencontré un problème que nous ne pouvons pas résoudre, la modification des dépendances ne met pas à jour le fichier de verrouillage de fil local, il met toujours à jour le fichier racine pour le référentiel mono vide sur lequel nous ne mettons pas à jour les dépendances (il a tout sous /packages gitignoré.

Avoir la possibilité de ne pas hisser les écritures de fichiers de verrouillage à la racine du référentiel mono serait formidable et les faire écrire au niveau du package.

En guise de note, j'ai également rencontré des problèmes de déploiement et de construction autour de Docker que d'autres ont mentionnés et cela résoudrait également cela!

Cette fonctionnalité me serait également très précieuse. Dans mon cas, j'ai un monorepo avec quelques packages déployés sur différentes plates-formes. L'une est une application Next.js déployée avec Now.sh et l'autre est un ensemble de fonctions cloud déployées sur Firebase.

Dans ces deux déploiements, le code source est regroupé et téléchargé pour l'installation et la construction dans le cloud. Ne pas avoir yarn.lock fichier

J'aimerais aussi pouvoir activer les fichiers fils.lock dans chaque espace de travail.

Je me rends compte que les espaces de travail de fil sont principalement destinés aux monorepos, mais notre cas d'utilisation est assez similaire à celui de @LeeCheneler .

Fondamentalement, nous avons créé une bibliothèque de composants React que nous utilisons comme dépendance dans différents projets (qui ont tous leurs propres dépôts). En utilisant des espaces de travail de fil, nous pouvons facilement référencer la version locale de la bibliothèque de composants et faire en sorte que les modifications se propagent rapidement à la version locale de nos autres projets. Nous n'avons pas non plus besoin de modifier le package.json lorsque nous passons en production car la dépendance library: "*" fonctionne sans aucun changement. Notre seul problème est que, sans fichiers de fils de verrouillage, les versions de production de chaque projet pourraient utiliser différentes versions de package.

Je dois imaginer que ce problème serait commun à tous les développeurs de packages qui utilisent des espaces de travail de fil.

Un autre problème critique avec un fichier de verrouillage de niveau supérieur est qu'il casse la mise en cache de couche de Docker. On serait généralement en mesure d'optimiser la mise en cache Docker en copiant d'abord le package.json et le fil.lock. Si Docker ne voit aucun changement dans ces fichiers, il utilisera une couche précédente. Si ce fichier de verrouillage est un seul pour l'ensemble du monorepo, cependant, toute modification dans un package invalide le cache. Pour nous, cela se traduit par des pipelines CI/CD ridiculement lents où chaque package est construit sans le cache. Il existe d'autres outils, comme Lerna, qui vérifient les modifications apportées aux packages pour exécuter certains scripts. Cela s'interrompt également car une modification de dépendance dans le fichier de verrouillage peut ne pas être détectée car elle est au niveau supérieur.

Désolé de soulever ce problème (un peu ancien), mais j'ai aussi un cas d'utilisation dans lequel cela serait utile. J'ai une dizaine de microservices qui sont hébergés et développés indépendamment, mais ce serait bien d'avoir un référentiel d'espace de travail central où vous pouvez taper yarn install pour installer des dépendances dans tous les dossiers, puis exécuter yarn start pour exécuter un script qui démarrera tous les microservices. C'est quelque chose qui pourrait être fait avec un script relativement simple mais cela semblait également faisable avec des espaces de travail de fil mais je ne pouvais pas le faire fonctionner tout en respectant le fil.locks dans chaque microservice

@nahtnam Je pense que l'idée de Yarn 1.x monorepo est un peu différente. Il ne s'agit pas de projets indépendants sous un même toit, il s'agit plutôt d'un grand projet singulier dont certains de ses composants sont exposés (appelés espaces de travail). Ces composants ne sont pas entièrement indépendants, mais peuvent être utilisés ainsi : le compilateur Babel comme une entité plus grande et preset-env comme sous-module. De plus, ils sont homogènes dans le sens où leurs dépendances sont unifiées : si certains packages dépendent de core-js , il devrait s'agir de la même version core-js dans chacun d'eux, car vous ne pouvez pas verrouiller différentes versions avec un seul fichier de verrouillage racine, il n'est pas non plus logique que les parties du projet dépendent de différentes versions. Et comme il s'agit d'un seul projet, tous ses composants sont automatiquement liés à la racine node_modules , ce qui est étrange pour des projets entièrement indépendants.

Donc, si vous développez un pack de microservices (qui sont indépendants, et certains d'entre eux ne seront pas touchés pendant des années tandis que d'autres seront créés/mis à jour, peut-être développés par différentes équipes), alors ils devraient avoir des fichiers de verrouillage personnels sans racine lock (le problème Docker va ici aussi). La seule question est de savoir quel outil vous aidera à exécuter des scripts. Lerna pourrait être une réponse car elle n'est pas liée au fil.

La seule question est de savoir quel outil vous aidera à exécuter des scripts. Lerna pourrait être une réponse car elle n'est pas liée au fil.

@the-spyke Pas seulement ça. yarn workspaces résout également, en liant les modules pour le développement de la même manière que npm link , ce qui est la principale raison pour laquelle nous l'utilisons. npm link ne fonctionne pas bien dans certains cas.

@the-spyke Merci ! Pour une raison quelconque, je pensais qu'il était inversé (espaces de travail lerna vs fil). J'ai regardé dans lerna et il semble que cela résolve mon problème

J'ai fini par utiliser des espaces de travail pour chaque projet sur lequel je travaille, en raison de la facilité d'avoir un package utilities séparé que je peux mettre à jour en cas de besoin (même s'il est publié), et du fait que Je n'ai pas besoin de réinstaller les dépendances si je veux forker un paquet (me permettant essentiellement de travailler sur deux branches en même temps, ce qui pour moi était du jamais vu), et chaque fois que je veux utiliser un paquet de mon utilities (qui comprend la plupart des choses que j'utilise habituellement), je peux l'utiliser tout de suite sans l'ajouter à package.json du deuxième paquet (mais c'est évidemment une bonne idée en cas d'installation séparée, et c'est nécessaire pour les importations automatiques IDE) ; tout fonctionne. @the-spyke fait valoir un bon point, peut-être que independent projects under one roof n'est pas le but des espaces de travail, et pourtant c'est à peu près ce que je semble faire ici : j'ai un seul référentiel monorepo-base , qui exclut le dossier packages , tandis que chaque dossier sous packages est un dépôt git indépendant distinct.

Bien sûr, cela m'amène au sujet de ce fil; puisque je ne commets pas tous les packages en un seul dépôt, le niveau racine yarn.lock n'a pas de sens. J'ai utilisé --no-lockfile pour tout installer et j'ai récemment rencontré un problème avec des versions conflictuelles de class-validator . Pour l'instant, je vais verrouiller tous les deps sur des versions spécifiques (honnêtement, ce niveau de contrôle a plus de sens pour moi) et voir comment cela fonctionne. Je vais relire toute la bande de roulement, il y a peut-être quelques astuces que je pourrais utiliser pour mon cas d'utilisation.

PS.
yarn why ne fonctionne pas sans fichier de verrouillage pour un, et j'ai remarqué que certaines personnes mentionnaient des problèmes avec App Engine. Je suppose que dans le cas où chaque paquet serait un dépôt séparé, le fichier de verrouillage pourrait être généré à chaque fois lors de l'installation (sans l'ajouter à VCS) ? Pas sûr de ce cas précis.

Malheureusement, la solution suggérée par @johannes-scharlach devient très compliquée si votre image construite nécessite des modules de nœud d'exécution qui ne sont pas inclus dans un dossier de construction, car vous devrez déterminer exactement quels modules doivent être exécutés et les copier minutieusement dans la dernière étape de la construction.

(légèrement hors sujet) @GrayStrider vous pouvez également utiliser le champ "résolutions" dans package.json - c'est le seul moyen de forcer une version sur une dépendance imbriquée, par exemple si vous voulez que tous les lodashs soient la version exacte, peu importe combien profondément imbriqué. Cependant, cela peut introduire des bugs très subtils qui seront difficiles à repérer.

Voici une solution sur laquelle nous sommes arrivés - avec un impact minimal sur le flux de travail Docker existant.

1. ln project/yarn.lock packages/package1/yarn.lock - crée un lien symbolique à partir de la racine yarn.lock dans chaque paquet.
2. Ajoutez COPY yarn.lock . à chaque packages/package1/Dockerfile
3. yarn install intérieur de Docker

Avantages :

• Ne pas avoir à copier l'intégralité de votre monorepo dans un calque d'image
• Vous n'avez pas besoin de fusionner vos fichiers Dockerfile au niveau du package en un seul Dockerfile à la racine
• Satisfait essentiellement aux exigences des fichiers de verrouillage de l'espace de travail

Inconvénients :

• --frozen-lockfile ne fonctionne pas. Comme les packages d'espaces de travail ne sont pas inclus dans le yarn.lock , donc le fil voit un package que vous avez "ajouté" au package.json qui n'existe pas dans le yarn.lock

Il s'agit néanmoins d'un inconvénient mineur, car vous pouvez le contourner en effectuant un yarn --frozen-lockfile comme première étape de votre pipeline CI/CD

Éditer:
En passant, je pense vraiment que la documentation de fil sur l'installation pourrait être un peu plus claire sur la façon dont le fichier de verrouillage est utilisé par le processus de résolution de package.

Éditer:
Il s'avère donc que git ne prend pas réellement en charge les liens physiques, il ne prend en charge que les liens symboliques logiciels, donc cette stratégie ne fonctionnera pas.

Une autre alternative consiste simplement à utiliser un gitook de pré-engagement pour copier le yarn.lock dans chacun de vos espaces de travail... ce n'est pas idéal car cela permet toujours des problèmes lors du déploiement à partir de votre machine locale.

@dan-cooke merci beaucoup pour vos idées, très appréciées!

@dan-cooke, cela interrompt la mise en cache de la couche Docker car une nouvelle dépendance dans n'importe quel espace de travail invaliderait la couche d'installation pour tous les fichiers Docker.

@migueloller Si la couche d'installation ne doit pas changer, vous ne devez pas utiliser un seul fichier de verrouillage pour tous les packages. L'aplatissement et le levage des dépendances dans une seule liste géante est l'objectif principal des espaces de travail. Ce n'est pas comme si cela "casse" le cache Docker, le cache est invalidé car les vraies dépendances ne sont pas spécifiées dans package.json , donc le code final de votre package dépend du contenu de yarn.lock . En conséquence, vous devez reconstruire tous les packages à chaque modification de yarn.lock et Docker fait tout correctement. Et ce n'est pas comme where every package is built without the cache car tous les builds pourraient réutiliser le calque avec yarn install (vous devrez probablement le configurer).

@migueller
Correct. Heureusement, nous n'ajoutons pas souvent de nouvelles dépendances, donc ce ne sera un problème qu'une fois par sprint au plus.

Et même alors, c'est un petit prix à payer (pour nous) pour des dépendances reproductibles dans Docker

@the-spyke, en effet. C'est pourquoi ce problème concerne la création d'un fichier de verrouillage individuel par package. De cette façon, la couche mise en cache n'est invalidée que lorsque les dépendances du package changent et est indépendante des autres packages.

Peut-être que cela vaut également la peine de déplacer cette discussion vers npm lui-même, qui prend également en charge les espaces de travail à partir de la v7.0.

J'ai fait des recherches sur des sujets connexes et j'aimerais ajouter quelques éclaircissements à mon commentaire ci-dessus (principalement destiné aux développeurs moins expérimentés, je suppose, car les problèmes auxquels je faisais face étaient dans une certaine mesure dus à mon incapacité à comprendre l'importance de lockfile ).

"verrouiller toutes les dépendances à une version spécifique" est appelé épingler ; malheureusement, cela n'empêchera pas les choses de casser potentiellement si les sous- dépendances sont mises à jour (derniers paragraphes de l'article ici ), ce que je n'ai pas pris en compte. C'est exactement ce que lockfile voulait empêcher de se produire.

J'ai perdu plus qu'assez d'heures à interrompre les mises à jour dans le passé à plusieurs reprises ; Je vais expérimenter avec l'utilisation de lockfile en monorepo, car je préfère gérer les conflits de fusion et les maux de tête organisationnels, que les bogues invisibles causés par des mises à jour mineures.

Ci-dessus dit, j'attends avec impatience tout progrès sur cette question

@migueloller Des fichiers de verrouillage individuels signifient des monorepos de fils individuels. Vous ne pouvez pas avoir de fichier de verrouillage pour un espace de travail car cela brise l'uniformité des profondeurs dans le Monorepo. Si vous voulez le faire, vous vous éloignez de l'idée originale de Yarn Monorepo : il s'agit d'unifier, de hisser et de réduire les profondeurs en une liste plate à la racine au lieu d'avoir différentes versions (et même des sous-arbres entiers) dans différents espaces de travail .

@the-spyke mais le problème d'origine est exactement le contraire. Un fichier de verrouillage par espace de travail.

Je ne comprends pas comment vous ne pouvez pas avoir un fichier de verrouillage par espace de travail.

Cela brise l'uniformité des profondeurs dans le Monorepo? Bien sûr pour le développement. Mais tout le but des dépendances partagées passe par la fenêtre lorsque vous devez déployer des micro-services légers à partir de chacun de vos espaces de travail

Les deps partagés et hissés n'ont de sens que dans le développement.

Pour qu'un espace de travail vive dans Docker, il nécessite un fichier de verrouillage.

@dan-cooke Comme vous pouvez le voir , j'ai également eu ce problème en 2018, mais maintenant j'ai un avis différent.

Vous dites Docker et Microservices. Mais que se passe-t-il si je développe un package npm régulier ? Je n'ai pas production sous-arborescence de dépendances dependencies . Donc, ce que je veux, c'est maximiser mon expérience de développement, et c'est ce que font parfaitement Monorepos et Yarn Workspaces.

Dans le même temps, si vous développez des microservices (MS), il existe 2 situations possibles :

1. Projets indépendants. Certains MS sont en développement, d'autres n'ont pas été touchés depuis des années. Dans ce cas, ils sont complètement indépendants. Il est possible d'avoir UserService utilisant [email protected] et MessagesService utilisant [email protected] . Ce n'est pas un monde facile où vous associez simplement les dossiers des espaces de travail à la racine node_modules . Donc, inutile d'avoir un fichier de verrouillage racine. Créez des fichiers séparés (racines) et gérez-les indépendamment. C'est ce qu'on appelle un Multirepo dans Yarn docs. Mais maintenant, ce que vous dites, c'est "Je veux exécuter des tâches dans différents dossiers du dossier racine pour plus de commodité". Et c'est un sujet complètement différent.

2. Les projets avec des dépendances unifiées comme Jest/Babel/etc. C'est pour cela que les espaces de travail ont été créés, mais dans les MS, il y a des exigences supplémentaires. Pendant les étapes de CI comme le linting et les tests, tout fonctionne bien car cela fonctionne de la même manière que vous le faites sur une machine de développeur : deps installés par Yarn dans les node_modules racine et aplatis. Juste en plus, vous cachez probablement la phase yarn install pour accélérer les builds simultanés.

   En production, c'est complètement différent : à partir de là, vous n'avez besoin que de deps pour un espace de travail et pour finir, comment installer ce package utils ? Doit-il être lié ou téléchargé en tant qu'archive ? Donc, ce dont vous avez vraiment besoin, ce n'est pas d'avoir des fichiers de verrouillage par espace de travail, mais d'avoir une commande comme yarn install --prod <workspace> que vous pouvez exécuter en spécifiant un espace de travail et elle n'installera que les services de production et en même temps ignorera les autres espaces de travail non référencés. Comme si mon data WS dépend de utils WS, mais pas de logging WS, alors logging lui-même et ses deps ne devraient pas apparaître dans node_modules . Un résultat similaire, mais une approche complètement différente d'un "fichier de verrouillage par espace de travail".

   Si vous publiez des packages de build dans un référentiel (npm, Arifactory, GutHub), vous pouvez obtenir un comportement similaire en copiant simplement le fichier de verrouillage dans un espace de travail et en faisant yarn install --prod ici. Il devrait avertir des fichiers obsolètes, mais au lieu de le recréer à partir de zéro avec de nouvelles versions, il devrait simplement en supprimer les excès de deps (juste essayé et semble légitime). Devrait être encore meilleur et robuste avec l'utilisation de Offline Mirror.

   Et à la fin, vous avez mis en œuvre des espaces de travail ciblés exactement pour Multirepos.

Donc, ce que je disais, c'est que le problème ne ressemble peut-être pas à ce qu'il est.

@le-espion
J'entends ce que vous dites. Je pense que cela dépend définitivement de la façon dont ce résultat est obtenu. Peut-être qu'un fichier de verrouillage par espace de travail n'est pas réellement le meilleur moyen d'obtenir le résultat souhaité. Vous faites de bons points.

Ce n'est certainement pas une solution "taille unique" de toute façon

@the-spyke, tu soulèves de bons points. Il faut peut-être réfléchir davantage aux problèmes que les espaces de travail Yarn ont été conçus pour résoudre et si son utilisation pour gérer de grands monorepos est alignée sur cette conception.

Je suis curieux de savoir comment vous résoudriez un scénario comme celui-ci :

.
└── packages
    ├── app1
    ├── app2
    ├── lib1
    ├── lib2
    └── lib3

lib3 est une bibliothèque partagée et dépend de app1 et app2 . lib1 n'est utilisé que par app1 et lib2 n'est utilisé que par app2 . D'après vos suggestions, lib1 et app1 devraient être dans leur propre espace de travail avec leur propre fichier de verrouillage et il en va de même avec lib2 et app2 . Maintenant, la question est que faire avec lib3 si _both_ app1 et app2 dépendent ? Peut-être pourrait-on faire en sorte que les deux espaces de travail ( app1 et app2 ) ajoutent lib3 à leur espace de travail, puis exécutent yarn install dans chaque application ? Yarn le permet-il ? Y aurait-il des conflits si l'on voulait exécuter à la fois app1 et app2 en développement localement (peut-être que app1 est une application React et app2 une API GraphQL) ? Cela semble pouvoir fonctionner.

La prochaine question à se poser serait « Comment obtient-on les avantages du levage avec cette méthode ? Par exemple, si app1 et app2 partagent beaucoup de dépendances communes, ce serait bien de les hisser. Je peux voir comment cela pourrait être hors de portée, cependant, et c'est un problème à résoudre par Yarn PnP (il ne copie pas les fichiers sur node_modules et a plutôt un cache partagé).

Je vais tenter le coup et je ferai un retour. Si cela finit par fonctionner, alors peut-être que nous utilisons mal les espaces de travail Yarn depuis le début...

EDIT : j'ai essayé et ça marche.

J'ai changé de position maintenant et je me rends compte que même si un fichier de verrouillage individuel par espace de travail peut être la première chose qui me vient à l'esprit lors de la gestion d'un monorepo entier avec des espaces de travail Yarn, ce n'est peut-être pas la bonne question. Une meilleure question pourrait être "Les espaces de travail Yarn sont-ils conçus pour gérer un monorepo ?". La réponse, comme d'habitude, est "ça dépend".

Si vous êtes Babel et que vous avez une seule équipe travaillant sur le monorepo et que tout est censé changer en même temps, alors oui, c'est pour cela que les espaces de travail Yarn ont été conçus. Mais si vous êtes une organisation avec plusieurs équipes et que vous utilisez un monorepo, vous ne voudrez probablement pas gérer l'intégralité du monorepo avec une seule racine d'espace de travail Yarn. Vous souhaitez probablement simplement utiliser le comportement par défaut de Yarn ou plusieurs racines d'espace de travail Yarn dans le monorepo. Cela sera déterminé par les applications que vous créez, le nombre d'équipes, etc.

Pour nous, il est devenu clair que pour chaque entité déployable (dans notre cas, il y a un Dockerfile), nous voulons avoir un yarn install séparé pour chacun (qu'il s'agisse d'une racine d'espace de travail ou non). Cela fournit de la clarté sur la propriété du code, permet des déploiements isolés qui se produisent à différentes cadences, résout les problèmes de mise en cache avec les fichiers de verrouillage et Docker, etc. Il y a cependant quelques inconvénients à cela :

• Qu'en est-il des packages node_modules dupliqués ? Il s'agit d'une classe courante de problèmes avec les monorepos et bien que les espaces de travail Yarn aident au levage, ce n'est pas une solution générale de monorepos. Il existe cependant d'autres solutions. Par exemple, Yarn PnP s'en occupe. Vous pouvez également utiliser Lerna sans fil et utiliser l'option --hoist .
• Qu'en est-il de l'utilité de l'exécution de la commande sur les espaces de travail pendant le développement ? Encore une fois, les espaces de travail Yarn vous permettent de le faire, mais cela ne signifie pas qu'il faut faire de l'ensemble du monorepo une racine de l'espace de travail Yarn. La construction de l'outillage et des scripts nécessaires sera différente pour chaque équipe et dépendra de leur monorepo. Les espaces de travail de fil n'ont probablement pas été conçus comme un exécuteur de tâches monorepo. On pourrait essayer de plier fil des espaces de travail un peu pour faire ce travail (c. -à- exécuter des scripts MNP à travers le monorepo en utilisant yarn workspace ... ) , mais il est important de garder à l' esprit qu'une seule racine de l' espace de travail pour l'ensemble monorepo ne sera probablement pas vous donner ce dont vous avez besoin à moins que vous ne soyez comme Babel, Jest, React, etc.

L'exécution d'un monorepo pose toute une série de problèmes. Par exemple, qu'en est-il du suivi des dépendances et de la reconstruction uniquement des éléments qui ont changé pour gagner du temps dans CI ? Les espaces de travail Yarn pourraient vous aider en vous permettant d'interroger le graphique de dépendance. Lerna le fait, par exemple, pour permettre le tri topologique des commandes en cours d'exécution. Yarn v2 vous permet également d'interroger le graphique de dépendance. Le gestionnaire de packages PNPM le fait également. Mais je dirais que selon la complexité du monorepo, on peut vouloir essayer des outils conçus pour cela (pas les gestionnaires de paquets) comme Bazel , Pants , Buck , etc.

@migueloller D'après vos exigences, je vois que vous n'avez pas besoin de packages strictement indépendants ou d'autres choses exotiques, vous voulez également des installations de développeur plus minces. Dans ce cas, vous devez commencer avec Yarn Monorepo standard : une seule racine et tous les packages en tant qu'espaces de travail. Vous aurez des temps d'installation plus rapides, une utilisation du disque plus faible et app1 utilisera des liens locaux lib1 et lib3 . Le seul inconvénient sera plus souvent l'invalidation du cache CI car l'ajout d'un devDep à lib1 mettra à jour le yarn.lock partagé. Mais généralement, vous ne mettez pas à jour les dépendances si souvent que vous vous souciez beaucoup de ce compromis.

lib1 peut dépendre de lodash@^4.5.0" and lib2 may depend on lodash@^4.10.0". Dans le cas de Monorepo, vous voulez qu'une seule version de lodash soit utilisée, donc Yarn installera quelque chose de plus récent compatible avec les deux spécificateurs comme ` [email protected] " hissé à la racine node_modules. Et en cas de mise à jour, vous mettez à jour cette seule version unifiée, de sorte que tous les espaces de travail restent toujours sur la même page. C'est le comportement souhaité.

Il y a aussi des situations où des équipes indépendantes développent des projets indépendants. Dans ce cas, proj1 peut vouloir rester à [email protected] avec proj2 ayant [email protected] et mettre à jour cela avec leurs propres cadences. Bien sûr, vous pouvez y parvenir en utilisant des spécificateurs plus stricts comme lodash@~4.5.0 , mais cela peut encore mettre à jour la dépendance de 2e niveau trop tôt. Donc, dans l'ensemble, ces projets peuvent être complètement indépendants, ils se trouvaient juste à l'intérieur d'un référentiel git. Dans ce cas, il n'y a aucune raison de les lier en tant que Yarn Monorepo et d'échanger l'indépendance contre un fichier de verrouillage partagé. Traitez-les simplement comme ce qu'ils sont : des projets séparés avec leur vie indépendante. Et cela s'appelle Multirepo. Sous Unix, tous vos répertoires sont sous / , mais cela ne signifie pas que tous les projets JS possibles sur votre PC doivent être un Monorepo :-)

La création d'une image Docker minimale possible pour une utilisation en production n'a aucun rapport avec Yarn, mais vous pouvez forcer Yarn à réutiliser un artefact de développement appelé yarn.lock et vous aider également dans cette tâche.

@the-spyke, dans cet exemple, je n'ai utilisé que 3 espaces de travail, mais dans notre référentiel actuel, nous avons plus de 20 espaces de travail avec une combinaison de bibliothèques et de charges de travail déployées pour le front-end et le back-end. La façon dont je le vois maintenant est que nous avons un monorepo (ou ce que vous appelez multirepo) où il sera probablement logique d'avoir plusieurs racines d'espace de travail Yarn avec des fichiers de verrouillage indépendants. Nous pensons utiliser une unité déployable comme unité de séparation, elle s'aligne bien avec les fichiers de verrouillage.

Je pense que pour moi, ce qui fait que cela fonctionne très bien, c'est le fait que les espaces de travail Yarn prennent en charge les chemins en dehors de la racine de l'espace de travail, même si le billet de blog initial dit le contraire. Par exemple, vous pouvez avoir ceci :

{
  "workspaces": [
    "../lib1",
    "../lib3"
  ]
}

Nous avons le même cas d'utilisation que @migueloller et une idée possible est que Yarn prenne en charge plusieurs ensembles d'espaces de travail, comme ceci :

{
  "workspaces": {
    "frontend-app": ["frontend", "common"],
    "backend-app": ["backend", "common"]
  }
}

Yarn conserverait deux fichiers de verrouillage supplémentaires (j'imagine que le yarn.lock existerait toujours):

.
└── monorepo/
    ├── yarn.frontend-app.lock
    ├── yarn.backend-app.lock
    └── packages/
        ├── frontend
        ├── backend
        └── common

Lors de la création d'une image Docker, par exemple pour le frontend, nous créons un contexte (par exemple via tar ) qui inclut ceci :

.
└── <Docker build context>/
    ├── yarn.frontend-app.lock
    └── packages/
        ├── frontend
        └── common

Ce à quoi je n'ai pas pensé en profondeur, c'est s'il est possible d'installer (lien dans node_modules ) les bonnes versions des dépendances si le frontend et le backend verrouillent des versions différentes. Mais purement du point de vue de haut niveau, les espaces de travail Yarn bidimensionnels sont probablement ce que nous recherchons.

(Quelque chose de similaire a également été publié ici .)

Il semble que vous n'ayez pas besoin d'un fichier de verrouillage par espace de travail, mais à la place, vous avez besoin de node_modules par espace de travail pour le déploiement

@gfortaine , si vous lisez la discussion vous vous

Il vaut peut-être la peine de mentionner que cela peut être fait dans les terres des utilisateurs. En utilisant le package @yarnpkg/lockfile , on peut analyser le fichier de verrouillage de niveau supérieur, puis en utilisant yarn workspaces info on peut déterminer les dépendances de l'espace de travail. En utilisant ces informations, ainsi que les package.json de chaque espace de travail, on peut générer un fichier de verrouillage par espace de travail. Ensuite, on pourrait le configurer en tant que script postinstall dans le référentiel pour garder ces fichiers de verrouillage individuels synchronisés avec celui de niveau supérieur.

Je pourrais essayer de construire ceci et faire rapport avec mes conclusions.

Il semble que je viens de trouver cette implémentation bien que pour pnpm : @pnpm/make-dedicated-lockfile

J'espère que cela aide

Mon besoin pour ce comportement (version par espace de travail, mais avoir toujours des fichiers de verrouillage dans chaque package) est que j'ai un monorepo imbriqué, où un sous-arbre est entièrement exporté vers un autre repo, il doit donc rester indépendant. En ce moment, je suis coincé avec lerna/npm et une logique personnalisée pour tenter d'égaliser les versions. Ce serait bien si fil (je suppose que v2, étant donné que c'est là que se trouve le support imbriqué ?)

Un script de post-installation pourrait tenter de gérer directement les fichiers de verrouillage, je suppose. Cela semble compliqué, mais ce serait bien de toute façon.