Vous êtes en plein sprint Node.js, les doigts qui volent sur une nouvelle route Express pour votre API sous Turso, vous sauvegardez — et vlan, le navigateur vous balance un « Cannot GET /new-route » comme si vous aviez tapé n’importe quoi.
Comment corriger Nodemon qui ne redémarre pas (bloqué sur l’ancien code) avec Turso / libSQL — voilà le piège qui tend la jambe aux devs alors que les bases de données edge comme Turso explosent en popularité. Turso, bâti sur libSQL, vend la simplicité de SQLite à l’échelle planétaire, avec des clients qui gardent des sockets persistants pour des requêtes éclair. Mais voilà le hic : Node.js refuse de crever tant que ce socket traîne, transformant les redémarrages de nodemon en farce. Les vieux processus zombifient sur le port 3000, les erreurs EADDRINUSE s’amoncellent, et vous redémarrez vos terminaux à coups de marteau comme en 2010.
Les chiffres confirment l’engouement. Turso a levé 32 millions de dollars, le paquet @libsql/client sur npm frôle les 100 000 téléchargements hebdo — les devs adorent cette base edge sans config. Pourtant ce bug nodemon ? Un classique qui rappelle les pools Redis des débuts, qui étouffaient les outils de hot-reload. Mon avis : l’ingénierie de Turso privilégie la vitesse en prod au détriment de l’ergonomie dev — malin pour scaler, bâclé pour itérer.
Pourquoi Nodemon merde avec les connexions persistantes de Turso ?
Nodemon surveille les fichiers, balance un SIGUSR2 au changement, s’attend à ce que votre app sorte proprement. Mais le socket de @libsql/client ? C’est une bouée de sauvetage en arrière-plan à laquelle Node s’accroche, refusant d’éteindre la lumière. Le terminal crache « EADDRINUSE :::3000 » — le doigt d’honneur du serveur zombie.
Fait : la boucle d’événements de Node traîne indéfiniment avec des handles ouverts. Turso ne ferme pas auto sur signaux, du coup les redémarrages foirent.
Pas exclusif à Turso. Tout lib avec des connexions longues — pools PostgreSQL ou WebSockets — déclenche le même piège. Mais le design socket-first de Turso l’amplifie, surtout en dev solo où vous zappez entre code et curl.
Et attention : ce n’est pas un bug, c’est la spec Node. Process.exit() snobe les sockets pendants sans close forcé.
Pour des requêtes rapides, @libsql/client maintient une connexion socket persistante et ouverte vers votre base Turso. Comme Node.js est conçu pour ne jamais sortir tant qu’un processus en arrière-plan est actif (comme une connexion base), quand nodemon tente de redémarrer votre app, l’ancien processus refuse de mourir.
Pile poil du guide de fix original. Vérité brutale, empaquetée en code.
La solution propre : arrêt gracieux en 20 lignes
Pas besoin d’un npm en plus. Accrochez les signaux, fermez les sockets, tuez le serveur.
D’abord, récupérez la ref de votre serveur :
const PORT = process.env.PORT || 3000;
const server = app.listen(PORT, () => {
console.log(`Server is running on port ${PORT}`);
});
Ensuite, en bas de se
