Nestia : typer NestJS de bout en bout, du décorateur au SDK client

Le problème que Nestia attaque : le type TypeScript s'arrête à la porte du contrôleur

Dans un projet NestJS classique, vous écrivez une interface ou une classe pour décrire le corps d'une requête, puis vous réécrivez la même information sous forme de décorateurs de validation, puis une troisième fois dans la documentation Swagger. Trois sources de vérité pour un seul contrat d'API. Nestia propose de n'en garder qu'une : le type TypeScript. Le README résume la promesse en une ligne, avec des décorateurs comme @TypedBody, @TypedParam, @TypedQuery, @TypedHeaders ou @TypedFormData, qui remplacent les décorateurs NestJS habituels. Le public visé est donc précis : une équipe qui écrit du NestJS en TypeScript strict, qui expose une API HTTP consommée par un frontend TypeScript, et qui en a assez de maintenir les DTO en double. Ce n'est pas une bibliothèque pour un backend JavaScript sans types, ni pour une API dont les clients sont écrits dans un autre langage, puisque l'essentiel de la valeur se trouve dans la génération de code TypeScript côté client.

Ce que la CLI nestia fabrique à partir de vos contrôleurs

Le mécanisme repose sur une analyse statique du code serveur. Le paquet @nestia/sdk expose un générateur de SDK client qui produit, d'après le README, une collection de fonctions fetch typées avec les structures DTO, comparaison faite avec tRPC. Le même paquet génère un document Swagger, des fonctions de test E2E automatiques et un simulateur de mockup décrit comme un backend embarqué dans le SDK, présenté comme similaire à msw mais entièrement automatisé. Le paquet @nestia/core fournit les décorateurs côté serveur, @nestia/e2e le programme de test qui exploite les fonctions E2E générées, et @nestia/benchmark un programme de mesure de performance qui s'appuie sur ces mêmes fonctions. Le point d'architecture à retenir est donc que la génération ne se fait pas à l'exécution par réflexion sur des métadonnées, mais à la compilation, à partir des types. C'est ce qui explique à la fois les gains annoncés et la contrainte de build. Le README cite des chiffres précis : validation à l'exécution présentée comme 20 000 fois plus rapide que class-validator, sérialisation JSON 200 fois plus rapide que class-transformer, et un gain global de 30x. Ces chiffres proviennent du projet lui-même et le README renvoie à un dossier benchmark/results dans le dépôt. Je ne les ai pas reproduits, et un rapport de benchmark publié par l'auteur d'une bibliothèque reste un rapport de l'auteur.

Mise en route : la CLI, pas seulement des paquets

L'installation ne se limite pas à un npm install. Le README liste un paquet nommé nestia, décrit comme un simple outil CLI, et les documents de configuration pointent vers une page Setup sur nestia.io. C'est cette CLI qui doit être exécutée dans votre chaîne de build pour produire le SDK et le document Swagger à partir des contrôleurs. Concrètement, cela veut dire que votre pipeline de compilation gagne une étape obligatoire : sans elle, les décorateurs typés n'ont pas de code généré derrière eux et le client ne peut pas être régénéré. Le nom des paquets à installer dépend de ce que vous voulez : @nestia/core pour les décorateurs serveur, @nestia/sdk pour la génération, @nestia/e2e et @nestia/benchmark pour les tests et les mesures, @nestia/editor pour l'éditeur TypeScript en ligne associé à Swagger-UI. Le README ne donne pas la ligne de commande exacte ni les clés de configuration du fichier de build dans l'extrait fourni, seulement le lien vers la page Setup. C'est un manque réel : vous ne pouvez pas évaluer le coût d'intégration sans ouvrir la documentation en ligne.

La contrainte de build est le vrai prix d'entrée

Une bibliothèque qui lit vos types TypeScript pour générer du code doit s'insérer dans le compilateur. Cela signifie que Nestia n'est pas une dépendance que vous ajoutez et oubliez : c'est une étape de compilation qui doit tourner avant le déploiement, et qui doit aussi tourner en développement pour que le SDK client reste synchronisé avec le serveur. Si votre équipe a déjà du mal à garder un build déterministe, ajouter une génération de code pilotée par les types ajoute une source de dérive possible entre le serveur et le SDK publié. Le README ne décrit pas de mécanisme de vérification automatique de cette synchronisation dans l'extrait fourni, et je ne peux pas affirmer qu'il en existe un. Autre point à surveiller : les décorateurs typés remplacent les décorateurs NestJS standards. Cela veut dire que le code qui dépend de @Body() ou @Param() de NestJS devra être réécrit, et que les intercepteurs ou pipes qui s'appuient sur les métadonnées de class-validator ne verront plus la même structure. La migration n'est pas un simple changement d'import.

Cas où Nestia est le mauvais outil

Si votre validation d'entrée repose sur class-validator avec des règles métier complexes exprimées en décorateurs personnalisés, Nestia vous demande de déplacer cette logique ailleurs, puisque le README positionne justement ses performances par rapport à class-validator et class-transformer. Une équipe qui a investi dans ces deux bibliothèques, avec des validateurs maison et des transformations imbriquées, paiera une réécriture qui n'a rien à voir avec le gain de performance annoncé. Deuxième cas défavorable : une API consommée uniquement par des clients non TypeScript. Le générateur de SDK produit des fonctions fetch typées, ce qui n'a de valeur que si le consommateur compile du TypeScript. Pour un client Python ou Go, il ne reste que le document Swagger, et vous payez alors la contrainte de build pour un artefact que d'autres outils produisent aussi. Troisième cas : un projet qui ne peut pas exécuter de commande de génération en CI, par exemple dans un environnement de build verrouillé. Sans cette étape, l'approche perd son intérêt principal.

Face à tRPC et msw : ce que Nestia déplace

Le README se compare lui-même à tRPC pour le SDK et à msw pour le simulateur. La différence d'approche mérite d'être posée clairement. tRPC part du routeur TypeScript et en déduit le client, ce qui suppose que le serveur et le client partagent le même espace de types et souvent le même dépôt. Nestia part d'un serveur NestJS existant, avec ses contrôleurs et ses décorateurs, et en extrait un SDK distribué comme paquet. Vous gardez donc une architecture NestJS classique, avec ses modules et son injection de dépendances, au lieu de basculer vers un modèle de routeur unique. Pour le mockup, msw intercepte les requêtes réseau dans le navigateur ou dans les tests et laisse le développeur écrire les gestionnaires. Nestia annonce un simulateur entièrement automatisé, dérivé des mêmes types que le serveur. L'avantage est évident si les types sont fiables, la limite aussi : un mockup généré ne couvre que ce que les types décrivent, et tout comportement conditionnel non exprimé dans le type doit être traité autrement. Le README ne détaille pas ce point dans l'extrait fourni.

Maintenance, licence et coût de mise à jour

Le dépôt n'est pas archivé et la dernière poussée date du 2 septembre 2026, avec une version v13.0.0 publiée le 21 août 2026 et des correctifs v13.0.1 et v13.0.2 dans les jours qui ont suivi. Le rythme de publication est donc actif, et une version majeure récente signifie que la documentation et les exemples en ligne peuvent décrire une API plus ancienne que celle que vous installerez. C'est un coût de maintenance à intégrer : une bibliothèque qui génère du code à partir de vos types doit être mise à jour en même temps que TypeScript, puisque le comportement du compilateur fait partie de son contrat. La licence est MIT, ce qui autorise l'usage commercial et la modification, avec l'obligation habituelle de conserver la notice de copyright et le texte de licence dans les copies distribuées. Je ne donne pas d'avis juridique : si vous redistribuez un SDK généré, faites vérifier la question par qui de droit dans votre organisation. Le README mentionne aussi des projets liés, @agentica pour l'appel de fonctions par LLM et @autobe pour la génération d'applications NestJS, ainsi qu'une page dédiée au développement de chatbot, ce qui élargit la surface à suivre au-delà du seul paquet @nestia/core.

Conclusion éditoriale

Nestia convient aux équipes qui écrivent déjà du NestJS en TypeScript strict et qui veulent supprimer la double déclaration DTO plus décorateurs de validation, au prix d'une étape de compilation supplémentaire dans le build. Il ne convient pas à un projet qui dépend fortement de class-validator ou de class-transformer, ni à une équipe qui ne peut pas faire tourner la CLI nestia en CI. Avant d'adopter, vérifiez trois choses dans votre dépôt : que votre tsconfig autorise la génération de code par transformation de types, que votre pipeline accepte une commande de build non standard, et que le paquet @nestia/sdk produit bien un SDK exploitable pour vos routes WebSocket, car c'est la partie la moins documentée dans le README.

Sources officielles

1. License: MIT
2. Project website
3. README
4. Releases
5. samchon/nestia on GitHub