unshared
Monorepo TypeScript de primitives réutilisables: types, guards, parsers, client HTTP, réactivité, scripts et helpers sans surprise.
Les helpers finissent toujours en API
J'ai regroupé dans unshared les petites primitives TypeScript qui finissent par apparaître dans tous les codebases: collections, strings, math, guards, validation, client HTTP, process helpers, réactivité, Vue, scripts, types avancés.
Le sujet n'est pas d'avoir un énième paquet de helpers. Le sujet est de traiter ces fonctions comme une API maintenue: noms explicites, tests, exports stables, pas de dépendance runtime inutile dans le package principal.
Le monorepo garde les primitives séparées
J'ai structuré le monorepo en packages séparés comme @unshared/string , @unshared/collection , @unshared/functions , @unshared/types , @unshared/validation , puis un package unshared qui réexporte les familles par sous-chemins.
Le package.json du package principal déclare sideEffects: false , des exports CJS/ESM/types, et des sous-chemins comme unshared/string ou unshared/validation . C'est une décision de packaging autant qu'une décision de code.
packages/string -> unshared/stringpackages/types -> unshared/typespackages/validation -> unshared/validationTester le banal
Le repo contient des tests sur les fonctions les moins glamour: toSlug , dedent , createSemver , groupBy , createQueue , parseCliArguments , guards de types, transformers, petites fonctions math. C'est ce niveau qui rend une librairie utilitaire utile dans la durée.
Un helper partagé sans test devient une croyance. Un helper partagé testé devient une convention que les autres projets peuvent reprendre sans relire l'implémentation.
Ce que ça dit d'une maintenance OSS
unshared montre une discipline de maintenance que j'applique souvent: versionner, tester, exporter proprement, garder les conventions d'une stack TypeScript cohérentes, et faire tenir le banal.
- Le repo utilise pnpm, TypeScript, Vitest, ESLint et un script de release maison.
- Les packages couvrent runtime, types, client HTTP, process, Vue et validation.
- Les exports par sous-chemins limitent le coût d'adoption.
- La valeur se mesure dans les projets qui arrêtent de réécrire le même helper légèrement différemment.