Frontières entre paquets

La question qui tranche

Huit paquets, et une seule règle pour savoir où va une chose : à quel public s'adresse-t-elle ? Pas « est-ce partagé ? » — tout finit par être partagé, et un paquet nommé d'après ce critère devient l'endroit où l'on range ce qu'on ne sait pas classer.

Un exemple qui rend la règle concrète. Le vocabulaire de rendu — ComponentTone, ComponentSize, ComponentVariant — tient en soixante-cinq lignes et sert à vingt-cinq fichiers. Le client HTTP en fait mille huit cents et sert à trois. Dans le même paquet, copier un Badge depuis le registre obligerait à installer un client HTTP complet, avec ses greffons, ses transports, son stockage de jetons et sa logique de réessai. Deux publics, deux paquets.

Où va quoi

• Le vocabulaire est fait de valeurs — ComponentTone est un nom que chaque plateforme traduit. Il vit auprès des couleurs et des espacements.
• toneClass ne l'a pas suivi, alors qu'il manipule le même vocabulaire : il fabrique un nom de classe CSS, donc une convention de rendu. Le natif traduira le même ton en objet de style et ne l'appellera jamais. Il vit dans @sia-ui/utils, auprès de cn.
• Le contrat de formulaire vit avec useLocalForm, son implémentation de référence. Les deux vont ensemble et ni l'un ni l'autre ne touche le DOM.
• RegistryItem décrit une entrée du registre : c'est la forme du paquet registry, qui n'a aucune raison de dépendre d'un paquet d'interface pour décrire un fichier à copier.
• Le client HTTP est @sia-ui/api. Il n'a aucun rapport avec l'interface : ni React, ni DOM, ni tokens. Il est utilisable seul, dans une application native, un script Node, un backend-for-frontend.

Ce qui ne se partage pas non plus : la forme des props. Le web étend HTMLAttributes et prend className, le natif étend ViewProps et prend style. Chaque composant déclare donc ses props chez lui — voir 31 — Source unique.

La pile

@sia-ui/tokens        valeurs : couleurs, espacements, mouvement, vocabulaire
@sia-ui/utils         fonctions sans dépendance
@sia-ui/api           client HTTP — indépendant de l'interface
@sia-ui/headless      comportement, avec React, sans plateforme
@sia-ui/react         primitives de runtime DOM
@sia-ui/react-web     composants DOM
@sia-ui/react-native  composants natifs, à venir

react-native dépendra exactement du même ensemble que react-web : tokens, utils, headless, plus api s'il en a besoin.

Ce que la règle interdit

• Un composant de react-web n'importe rien depuis un autre dossier que le sien : la CLI ne sert que components/<Nom>/, et un import vers ../../ arrive cassé chez l'utilisateur. C'est vérifié par packages/cli/src/install.test.ts.
• headless n'importe pas react-web. tokens n'importe pas React.
• Un réexport n'est pas une frontière : un dossier qui ne fait que réexporter un paquet voisin est une indirection, pas une couche.

La prochaine couture

@sia-ui/tokens mélange des valeurs brutes — couleurs, espacements, vocabulaire — et de la génération CSS : toCssVariables, themeVariables. Le natif voudra les premières sans la seconde. Ce n'est pas bloquant, le tree-shaking s'en charge, mais c'est à examiner le jour où le paquet natif existera.