Espaces de travail

Les espaces de travail (workspaces) sont une nouvelle manière pour configurer votre architecture de package qui est disponible par défaut depuis Yarn 1.0. Cela vous permet d’installer plusieurs packages en exécutant une fois Yarn install afin de les installer en un seul passage.

Pourquoi voulez-vous faire cela ?

Vos dépendances peuvent être reliées entre elles, ce qui signifie que vos espaces de travail peuvent compter les uns sur les autres en utilisant toujours le code disponible à jour. C’est aussi un meilleur mécanisme que yarn link car il affecte uniquement l’arborescence de votre espace de travail plutôt que votre système tout entier.
Toutes les dépendances de votre projet seront installées ensemble, donnant à Yarn plus de latitude pour mieux les optimiser.
Yarn utilisera un fichier de verrouillage unique plutôt qu’un seul par projet, ce qui signifie moins de conflits et des relectures plus faciles.

Comment l’utiliser ?

Ajoutez le texte suivant dans un fichier package.json. À partir de maintenant, nous appellerons ce répertoire la « racine de l’espace de travail » :

package.json

{
    "private": true,
    "workspaces": [
        "workspace-a",
        "workspace-b"
    ]
}

Veuillez noter que private: true est obligatoire ! Les espaces de travail ne sont pas destinés à être publiés, nous avons ajouté cette mesure de sécurité pour s’assurer que rien ne peut être accidentellement exposer.

Une fois ce fichier créé, créez deux nouveaux sous-dossiers nommés workspace-a et workspace-b. Dans chacun d’eux, créez un autre fichier package.json avec le contenu suivant :

workspace-a/package.json :

{
    "name": "workspace-a",
    "version": "1.0.0",

    "dependencies": {
        "cross-env": "5.0.5"
    }
}

workspace-b/package.json :

{
    "name": "workspace-b",
    "version": "1.0.0",

    "dependencies": {
        "cross-env": "5.0.5",
        "workspace-a": "1.0.0"
    }
}

Enfin, exécutez yarn install quelque part, idéalement à l’intérieur de la racine de l’espace de travail. Si tout fonctionne bien, vous devriez maintenant avoir une hiérarchie de fichiers similaire :

/package.json
/yarn.lock

/node_modules
/node_modules/cross-env
/node_modules/workspace-a -> /workspace-a

/workspace-a/package.json
/workspace-b/package.json

Et c’est tout ! En exigeant le workspace-a depuis un fichier situé dans le workspace-b, cela va permettre d’utiliser maintenant le code, actuellement situé à l’intérieur de votre projet, plutôt que ce qui est publié sur Github, et le package cross-env a été correctement exposé et mis à la racine de votre projet pour être utilisé par les deux : workspace-a et workspace-b.

Peut-on le comparer à Lerna ?

Les espaces de travail de Yarn sont des primitives de bas niveau qui utilisent des outils comme Lerna qu’on peut (et doit !) utiliser. Ils n’essayeront jamais de prendre en charge la fonctionnalité de haut niveau offerte par Lerna, mais en mettant en œuvre la logique de base de la résolution et les étapes de liaison à l’intérieur de Yarn, nous espérons pouvoir activer de nouveaux usages et améliorer les performances.

Trucs & astuces

Le champ workspaces est un tableau contenant les chemins d’accès à chaque espace de travail. Puisqu’il peut être fastidieux de garder une trace de chacun d’eux, ce champ accepte également des glob patterns ! Par exemple, Babel fait référence à tous ses packages via une seule directive packages/*.
Les espaces de travail sont suffisamment stables pour être utilisés dans des grandes applications et ne devraient pas changer quoi que ce soit sur la manière dont fonctionne l’installation, mais si vous pensez qu’ils cassent quelque chose, vous pouvez les désactiver en ajoutant la ligne suivante dans votre fichier Yarnrc :
```
  workspaces-experimental false
```

Limitations & mises en garde

L’aspect du package sera différent entre votre espace de travail et ce que vos utilisateurs obtiendront (les dépendances de l’espace de travail seront hissées plus haut dans la hiérarchie du système de fichiers). Faire des hypothèses à propos de cette disposition était déjà hasardeuse car le processus de levé n’est pas normalisé, donc théoriquement rien de nouveau ici.
Dans l’exemple ci-dessus, si workspace-b dépend d’une version différente de celle référencée dans workspace-a du package.json, la dépendance est installée depuis Github au lieu de la lier à votre système de fichiers local. C’est parce que certains packages ont réellement besoin d’utiliser des versions précédentes afin de construire les nouveaux (Babel est l’un d’entre eux).
Les espaces de travail doivent être des enfants de la racine de l’espace de travail en terme de hiérarchie de dossiers. Vous ne pouvez pas et ne devez pas faire référence à un espace de travail situé en dehors de cette hiérarchie de système de fichiers.
Les espaces de travail imbriqués ne sont pas supportés pour l’instant.

Espaces de travail