Il y a trois semaines, j'ai publié mon premier package sur npm. Sept kilo-octets, aucun téléchargement, et cette petite fierté qu'on ressent quand on voit son nom dans le registre officiel. J'ai mis plus de temps à choisir le nom qu'à écrire le code.
Je voulais extraire un hook React que j'utilisais dans deux projets différents — useViewTransition. Rien d'extraordinaire : une sucrerie autour de l'API native du navigateur, avec une gestion propre des fallback.
La prémisse
Publier un package, c'est écrire un contrat. Tu promets à une poignée d'inconnus que ton bout de code ne va pas casser leur build samedi à deux heures du matin.
Un package, c'est moins un produit qu'une relation.
L'extraction
La première tâche, c'est l'archéologie. Retrouver toutes les variables implicites, toutes les dépendances croisées, tous les petits // TODO qu'on s'était juré de nettoyer.
// Avant
export function useViewTransition(router) {
const route = router.current;
}
// Après
export function useViewTransition(
callback: () => void | Promise<void>,
options?: { skip?: boolean }
) {
if (options?.skip || !document.startViewTransition) {
return callback();
}
return document.startViewTransition(callback);
}Dessiner l'API publique
- Une fonction, un travail
- Les booléens sont des pièges
- Les types exportés comptent autant que les valeurs
- Un README court vaut mieux qu'un long
Semver n'est pas un choix
J'ai voulu faire le malin et publier en 0.1.0. Un mainteneur m'a rappelé qu'un 1.0.0 honnête est toujours mieux qu'un 0.9.9 timide.
Après le premier 1.0.0
Le code est la partie facile. Le vrai travail commence après : répondre aux issues, décider quand dire non. Un package publié, c'est un être vivant.