# Un registre npm privé pour partager des composants front entre plusieurs thèmes

> Publier un composant JavaScript maison en interne évite les copier-coller entre thèmes qui finissent toujours par diverger avec le temps.

- Auteur : Clément Hadrot
- Publié le : 2025-10-03
- Mis à jour le : 2025-10-03
- Catégorie : Outils & workflow
- URL : https://wpmoderne.dev.wordpress-developpement.fr/outils/registre-npm-prive-composants-front/

## L’essentiel

- Un copier-coller entre thèmes finit toujours par diverger silencieusement
- Un registre npm privé permet de versionner un composant partagé comme n'importe quel paquet
- La mise à jour d'un composant reste explicite, jamais automatique

`npm install @agence-interne/galerie-lightbox` : cette commande résume à elle seule le changement opéré. Le même composant de galerie en lightbox, initialement écrit pour un thème particulier, se retrouvait copié-collé dans cinq autres projets au fil des mois, chacun avec ses propres corrections mineures jamais reportées ailleurs. Un correctif d'accessibilité appliqué sur un thème restait invisible sur les cinq autres, jusqu'à ce qu'un audit le révèle par hasard.

Ce constat a motivé la mise en place d'un registre npm privé interne, réservé aux composants JavaScript front réutilisables entre projets. La question du partage de code PHP entre projets, déjà traitée séparément via un mécanisme distinct, ne fait pas l'objet de cet article.

## Le choix du registre plutôt que d'un simple dépôt Git

Une alternative plus simple aurait consisté à référencer directement un dépôt Git comme dépendance dans le fichier `package.json` de chaque thème. Cette approche a été écartée pour une raison précise : elle ne permet pas de distinguer clairement les versions publiées des versions en cours de développement, et complique le suivi des correctifs appliqués à un composant donné. Un registre npm, même privé, impose une discipline de version explicite via le champ `version` du composant, suivant les règles de versionnage sémantique.

Le registre choisi s'appuie sur un serveur auto-hébergé compatible avec le protocole npm, accessible uniquement depuis le réseau interne de l'agence et depuis les exécuteurs de la CI via un jeton d'authentification dédié.

## Publier un composant partagé

> L'essentiel à retenir : Un copier-coller entre thèmes finit toujours par diverger silencieusement ; Un registre npm privé permet de versionner un composant partagé comme n'importe quel paquet ; La mise à jour d'un composant reste explicite, jamais automatique

Chaque composant partagé vit dans son propre dépôt, avec son propre fichier `package.json` configuré pour publier vers le registre interne plutôt que vers le registre public par défaut.

```
{
  "name": "@agence-interne/galerie-lightbox",
  "version": "1.3.0",
  "publishConfig": {
    "registry": "https://npm.interne.agence.example"
  },
  "main": "dist/galerie-lightbox.js"
}
```

La publication d'une nouvelle version se fait avec la commande habituelle `npm publish`, exécutée depuis un poste ou depuis la CI après passage des tests du composant. Chaque thème qui l'utilise déclare ce paquet comme dépendance classique dans son propre `package.json`, avec une contrainte de version précise pour éviter qu'une mise à jour majeure ne s'installe sans validation.

## Mettre à jour un composant sans surprise

Le point le plus délicat concernait la propagation des mises à jour : il fallait éviter qu'une correction sur le composant partagé ne se répercute automatiquement et silencieusement sur tous les thèmes qui en dépendent. La contrainte de version dans chaque thème est donc fixée avec un préfixe restrictif plutôt qu'un caret par défaut, ce qui impose une action explicite pour changer de version.

- Version fixée précisément dans chaque thème consommateur
- Mise à jour déclenchée manuellement, jamais automatiquement par la CI
- Journal de changement tenu à jour dans chaque dépôt de composant

Cette rigueur a un coût : une correction de sécurité sur un composant partagé doit être reportée manuellement dans chaque thème concerné. Ce coût reste jugé acceptable au regard du problème initial, la divergence silencieuse entre copies, qu'il visait justement à éliminer.

## Ce que ce registre a changé concrètement

Six thèmes différents partagent aujourd'hui le même composant de galerie, la même bibliothèque de formulaires multi-étapes, et un composant d'affichage de disponibilités utilisé sur plusieurs sites de réservation. Un correctif d'accessibilité appliqué une seule fois se propage désormais à tous les projets qui le souhaitent, par une simple montée de version explicite, plutôt que par une recherche manuelle de chaque copie existante.

Le registre reste de taille modeste, une douzaine de composants publiés à ce jour, ce qui en facilite grandement la maintenance par une seule personne au sein de l'équipe front.

## En résumé

Un registre npm privé transforme un ensemble de copier-coller dispersés en un catalogue de composants versionnés et traçables. Le gain principal ne réside pas dans la vitesse de développement d'un nouveau thème, mais dans la certitude qu'un correctif appliqué une fois reste réellement disponible pour tous les projets qui en ont besoin, sans dépendre de la mémoire de qui a copié quoi et où.