shadcn/ui : posséder le code source des composants

La plateforme a commencé sur NextUI, une bibliothèque de composants installée traditionnelle, et a migré vers shadcn/ui en cours de projet. Le pourquoi compte plus que l'une ou l'autre bibliothèque seule.

La plupart des bibliothèques de composants — NextUI, MUI, Chakra — s'installent comme une dépendance : tu importes des composants pré-construits et compilés, et personnaliser signifie combattre l'API de thème propre à la bibliothèque. shadcn/ui est une CLI qui génère le vrai code source des composants directement dans ton dépôt — des primitives Radix en dessous pour le comportement d'accessibilité, des utilitaires Tailwind par-dessus, et tu possèdes les fichiers.

npx shadcn add button
# écrit un vrai Button.tsx dans ton dossier de composants — à toi de l'éditer librement

Ça l'a emporté pour quelques raisons concrètes :

• Pas d'API de thème à combattre. Restyler en mode sombre, RTL pour l'arabe, ou un rafraîchissement visuel complet est une édition de code normale, pas l'apprentissage d'un système de thème en boîte noire.
• Pas de bloat de bundle opaque — seuls les composants réellement utilisés existent dans la base de code tout court.
• Ça convient à un monorepo d'applications partageant une couche d'UI, puisque les composants ne sont que du code qui se compose en un paquet partagé dont toutes les applications importent.

Le commit de migration a groupé la correction de plusieurs vrais bugs à côté du rafraîchissement visuel — une course d'état d'authentification, une config Docker d'OAuth Google, le rendu des avatars. Pas une coïncidence : une réécriture à grande échelle est souvent le moment où plusieurs petits bugs sans rapport se font enfin remarquer et corriger ensemble, parce que toucher à chaque écran force un regard neuf sur des choses qui étaient discrètement cassées. Cette même migration a aussi fait passer la config Docker front-end de neuf Dockerfiles à deux et simplifié la config TypeScript.

Tailwind en dessous est utilitaire d'abord — le style composé directement dans les noms de classe JSX. Une seule config de couleur et de thème partagée sur chaque application (l'équivalent propre à React Native via NativeWind) est ce qui garde le langage visuel cohérent sur des applications vraiment séparées sans synchroniser à la main un système de design sur chacune.