Bien démarrer avec un monorepo, un linter et un formatter

Dans cette série, nous commencerons depuis zéro. C'est la meilleure façon de comprendre et d'apprendre. Nous allons mettre en place un monorepo, configurer un linter et un formatter.

Mise en place du projet ​

Un monorepo est un dépôt qui abrite plusieurs projets. Dans notre cas, nous aurons le package @barbapapazes/huchet-vue, deux playgrounds et un storybook. L'utilisation d'un monorepo permet de gérer tous ces projets au sein d'un seul dépôt, facilite le partage de code et permet une installation unique des dépendances, maintenant tout synchronisé et compatible. Nous pourrions facilement envisager d'ajouter d'autres packages à l'avenir, comme une configuration personnalisée de Tailwind CSS ou une bibliothèque utilitaire partagée.

Pour créer un monorepo, nous allons utiliser pnpm workspaces, une fonctionnalité du gestionnaire de paquets pnpm qui installe les dépendances de manière intelligente, en utilisant des liens durs et des liens symboliques pour économiser de l'espace disque et du temps.

Tout d'abord, créez un nouveau répertoire et initialisez un nouveau dépôt git :

mkdir huchet-vue && cd huchet-vue && npm init -y

Ouvrez ce dossier dans votre éditeur de code et modifiez le fichier package.json :

{
  "name": "huchet-vue",
  "version": "0.0.0",
  "type": "module",
  "private": true
}

Ce package.json est le fichier principal pour notre monorepo. Les packages futurs auront chacun leur propre package.json. Le fichier principal n'inclura que les dépendances et les scripts ayant un impact sur l'ensemble du monorepo, pas ceux partagés entre les packages.

Avant de continuer, ajustez un paramètre de pnpm en créant un fichier .npmrc :

echo "shamefully-hoist=true" > .npmrc

Ce paramètre permet à pnpm de hisser les dépendances vers le dossier node_modules racine. Bien que ce ne soit pas par défaut ou recommandé, cela est nécessaire dans notre cas.

Linter et Formatter ​

Ajouter un linter et un formatter garantit que notre code reste propre et cohérent, une exigence fondamentale pour tout projet, surtout une bibliothèque de composants utilisée par d'autres développeurs.

Couramment, on utilise Prettier comme formatter et ESLint comme linter. Les deux ont d'amples plugins et configurations, mais leur intégration peut être complexe. Comme je ne suis pas partisan d'un style de code spécifique, tendre vers le moins de configuration est préférable.

Pour ce projet, comme pour tous mes projets, nous allons utiliser la configuration ESLint de Anthony Fu. C'est une configuration très affirmée utilisant ESLint et Stylistic.

Installez-le avec une simple commande :

pnpm dlx @antfu/eslint-config@latest && pnpm add -D typescript

Ajoutez deux scripts à votre fichier package.json :

{
  "scripts": {
    "lint": "eslint .",
    "lint:fix": "eslint --fix ."
  }
}

Mettez à jour le fichier eslint.config.ts pour prendre en charge Vue, TypeScript, et Stylistic :

import antfu from '@antfu/eslint-config'

export default antfu({
  stylistic: true,
  vue: true,
  typescript: true
})

Vous pouvez maintenant linter votre code :

pnpm run lint

Et corriger automatiquement les problèmes :

pnpm run lint:fix

Définir notre Monorepo ​

Avec le linter et le formatter configurés, nous pouvons commencer à définir notre monorepo.

Nous aurons la structure suivante :

.
├── .histoire
│   └── package.json
├── package.json
├── packages
│   └── huchet-vue
│       └── package.json
└── playground
    ├── nuxt
    │   └── package.json
    └── vue
        └── package.json

Pour l'instant, créez le dossier packages et le package huchet-vue avec son fichier package.json. D'autres packages seront ajoutés dans les prochains articles de cette série.

mkdir -p packages/huchet-vue
echo '{\n"name": "@barbapapazes/huchet-vue",\n"type": "module",\n"version": "0.0.0"\n}' > packages/huchet-vue/package.json

Avoir deux packages nous permet de les définir dans un fichier pnpm-workspace.yaml à la racine de notre monorepo :

echo 'packages:\n  - packages/*' > pnpm-workspace.yaml

Ce fichier indique à pnpm où trouver les packages dans notre monorepo. Il lie les packages ensemble, évite la duplication, partage les dépendances et facilite l'installation avec une seule commande.

Même avec un monorepo, chaque package doit être traité comme un projet autonome, ayant son propre package.json, ses dépendances et ses scripts.

Installez les dépendances depuis la racine du projet :

pnpm install

Vous constaterez que pnpm reconnaît 2 packages :

Scope: all 2 workspace projects

Dans le prochain article, nous créerons notre premier composant dans notre monorepo nouvellement établi.