shadcn/ui a déployé les registres GitHub, une fonctionnalité qui transforme n'importe quel dépôt GitHub public en registre installable. En déposant un simple fichier registry.json à la racine d'un dépôt, les développeurs permettent à quiconque de récupérer composants, configurations, documentation et même règles d'agents IA directement via la CLI shadcn — sans serveur de registre à héberger ni fichiers JSON générés à publier.
Cette sortie prolonge le système de registres que shadcn a popularisé pour distribuer des composants React, et en supprime l'un des plus gros points de friction. Jusqu'ici, partager un registre imposait de monter un serveur ou de publier du JSON statique sur un point d'accès hébergé. Avec les registres GitHub, le dépôt lui-même devient la source de vérité.
Points clés
- N'importe quel dépôt GitHub public peut devenir un registre en ajoutant un fichier
registry.jsonà sa racine. - Les éléments s'installent avec un format d'adresse simple :
pnpm dlx shadcn@latest add owner/repo/item. - Les éléments de registre ne se limitent pas aux composants React — il peut s'agir de fichiers sources, de configurations, de docs, de modèles, de workflows CI, de configurations MCP et de règles d'agents.
- Aucun serveur de registre ni point d'accès JSON hébergé n'est requis ; le dépôt est le registre.
- Les installations peuvent être figées sur un tag, un SHA de commit ou une branche pour des résultats reproductibles.
Comment ça marche
Pour publier, un mainteneur ajoute un fichier registry.json à la racine d'un dépôt public. Le fichier se conforme au schéma de registre de shadcn et décrit chaque élément partageable : ses fichiers, ses destinations cibles dans le projet consommateur et ses éventuelles dépendances.
Côté consommateur, l'installation utilise une adresse au format owner/repo/item. Par exemple, pnpm dlx shadcn@latest add acme/toolkit/project-conventions récupère un élément nommé project-conventions depuis le dépôt toolkit appartenant à acme. Comme l'adresse est résolue directement auprès de GitHub, il n'y a aucune étape d'enregistrement d'espace de noms.
La reproductibilité est intégrée. Les consommateurs peuvent ajouter une référence Git pour verrouiller l'installation sur une version précise — un tag de version comme #v1.0.0, un SHA de commit complet ou un nom de branche. Cela rapproche la consommation d'un registre d'une dépendance versionnée plutôt que d'un copier-coller ponctuel.
La CLI fournit aussi des commandes complémentaires pour travailler avec ces registres : registry validate vérifie que le registry.json d'un dépôt est bien formé, list énumère les éléments exposés par un registre, search filtre les éléments par requête, et l'option --dry-run prévisualise ce qu'une installation écrirait avant de toucher au système de fichiers.
Au-delà des composants
Le changement le plus marquant porte sur ce qui compte comme élément de registre. Les registres de shadcn ne sont plus seulement un canal de livraison pour les composants d'interface. La documentation prend explicitement en charge la distribution de fichiers de configuration tels que les réglages Vitest, Prettier et TypeScript, aux côtés de la documentation, des modèles, des workflows CI/CD, des configurations MCP et des règles d'agents.
Cette dernière catégorie tombe au cœur du moment actuel. Alors que les équipes standardisent le comportement de leurs agents de code IA d'un projet à l'autre, un registre capable de livrer des conventions de type AGENTS.md, des règles de prompts et des configurations d'outils via le même canal que les composants transforme l'échafaudage de projet en une unité installable unique. Une équipe peut empaqueter tout son style maison — composants, linting, configuration de tests et consignes d'agents — et laisser n'importe quel dépôt le récupérer en une seule commande.
Impact
Pour l'écosystème front-end, les registres GitHub abaissent à presque zéro la barrière à la maintenance d'une bibliothèque de composants partagée. Mainteneurs indépendants comme équipes de plateforme internes peuvent distribuer des briques de base sans exploiter d'infrastructure, et les consommateurs obtiennent des installations versionnées et auditables plutôt que des archives de paquets opaques.
Une communauté grandissante gravite déjà autour du format de registre — annuaires qui indexent les registres de confiance, traqueurs de changements de style RSS, et des dizaines de bibliothèques de composants tierces bâties sur la CLI. Faire du dépôt lui-même le registre supprime la taxe de configuration restante pour cette communauté, et devrait accélérer le nombre de registres publics.
Pour le code privé, une réserve s'impose : les dépôts privés et les hôtes GitHub Enterprise ne sont pas pris en charge par le format d'adresse GitHub. Les équipes ayant besoin d'une distribution authentifiée doivent continuer à utiliser des registres d'espace de noms avec identifiants.
Contexte
shadcn/ui s'est imposé en rejetant le modèle classique de paquet npm pour les kits d'interface. Plutôt que d'installer une dépendance opaque, les développeurs copient le code source du composant dans leur propre base de code, où ils en sont propriétaires et peuvent le modifier. Le système de registres a formalisé ce flux copier-dans-votre-projet en un format distribuable, et la CLI l'a rendu scriptable.
Les registres GitHub sont l'aboutissement logique de cette philosophie : si vos composants existent déjà sous forme de simples fichiers dans un dépôt, le dépôt devrait suffire pour les partager.
Et ensuite
Attendez-vous à ce que l'annuaire de registres s'étoffe rapidement à mesure que les mainteneurs convertissent leurs dépôts existants avec un seul fichier, et surveillez la croissance des registres de règles d'agents et de configurations aux côtés des bibliothèques de composants. Avec des installations reproductibles et figées sur une référence, et la prise en charge de tout type de fichier, la frontière entre un registre d'interface et un outil d'échafaudage de projet polyvalent continue de s'estomper.
Source : shadcn/ui — GitHub Registries