Guide de migration vers NestJS 12 : ESM, schéma standard et observabilité

NestJS 12 est arrivé, et contrairement à une mise à jour majeure typique, cette version ne se concentre pas sur une seule fonctionnalité phare.

Au lieu de cela, elle touche plusieurs aspects de l’écosystème NestJS en même temps, les mettant à jour pour refléter la réalité du développement backend aujourd’hui.

Parmi les mises à jour les plus notables, on trouve :

• Les paquets Nest sont désormais distribués en ESM
• Une validation basée sur Standard Schema
• Une sérialisation basée sur Standard Schema
• Une capacité d’observation intégrée grâce à @nestjs/observe
• Une CLI NestJS réécrite
• Un support Rspack pour de nouvelles configurations monorepo
• Vitest et oxlint disponibles par défaut dans les nouveaux projets
• Une détection plus intelligente des routes conflictuelles
• Des codes d’erreur que les outils peuvent interpréter
• Un journalisation structurée, adaptée aux machines

Si vous gérez déjà une base de code NestJS, un détail devrait immédiatement dissiper tous vos soucis :

Il n’est pas obligatoire de passer votre application à ESM simplement parce que NestJS 12 lui-même est distribué en format ESM.

Ce fait seul transforme ce qui pourrait sembler être une mise à niveau disruptive en quelque chose que vous pouvez adopter à votre propre rythme.

NestJS 12 se concentre sur la mise à jour du framework

NestJS est largement utilisé pour créer des services backend bien organisés basés sur Node.js et TypeScript.

Sa structure globale n’a pas changé et reste reconnaissable pour quiconque l’a déjà utilisé :

NestJS 12 Is About Modernizing the Framework

NestJS has become one of the popular ways to build structured backend applications with Node.js and TypeScript.

Its architecture is familiar:

Ce qui a changé, c’est le contexte du monde Node.js environnant.

L’adoption d’ESM continue de croître dans l’écosystème.

Des bibliothèques de schéma comme Zod gagnent en popularité.

De nouveaux outils de compilation, plus rapides, remplacent progressivement les anciens outils de build.

L’observabilité est de plus en plus considérée comme une priorité majeure pendant le développement, et non comme quelque chose qui est ajouté après la mise en production d’un service.

NestJS 12 rattrape essentiellement toutes ces tendances en même temps.

Cependant, il est à noter que rien de tout cela ne force les applications existantes à adopter tout cela dès le premier jour.

1. Les paquets principaux de Nest sont désormais livrés en ESM

Peut-être le changement le plus visible dans cette version est que les paquets principaux de Nest sont désormais publiés au format ESM.

Si votre projet est basé sur CommonJS, cela pourrait sembler nécessiter une réécriture importante.

Heureusement, les versions modernes de Node.js prennent en charge require(esm).

En pratique, cela signifie que la plupart des applications CommonJS peuvent continuer à fonctionner telles quelles, sans conversion complète en ESM.

Par exemple, cette ligne fonctionne toujours exactement comme avant :

const { NestFactory } = require('@nestjs/core');

Vous n’êtes pas tenu de le réécrire comme suit :

import { NestFactory } from '@nestjs/core';

Cela dit, NestJS 12 augmente bien la version minimale de Node.js requise.

Plus précisément, vous aurez besoin d’une des versions suivantes :

Node.js 20.19+
or
Node.js 22.12+

Node.js 21.x n’est pas explicitement pris en charge.

Ainsi, avant de modifier vos dépendances NestJS, vérifiez quelle version de Node.js vous utilisez :

node --version

Vérifier cela tôt dans votre pipeline CI/CD constitue également une précaution judicieuse.

2. Passer à ESM est un choix, pas une exigence

Cet aspect mérite une attention particulière pour les équipes qui gèrent des projets existants.

Deux migrations distinctes ont lieu ici.

NestJS lui-même met ses packages à jour vers ESM.

Cependant, votre application n’est pas obligée de le faire immédiatement.

En d’autres termes, cette configuration est tout à fait valide :

Existing CommonJS Application
↓
NestJS 12
↓
Continue running CommonJS

plutôt que d’être contraint de le faire :

CommonJS
↓
Rewrite everything
↓
ESM
↓
NestJS 12

Néanmoins, l’utilisation d’outils personnalisés pour votre projet peut encore engendrer des problèmes.

Il est utile de vérifier à nouveau :

• les scripts Bootstrap personnalisés
• les pipelines de construction
• les exécuteurs de tests
• la configuration du bundler
• les schémas d’import non standard
• les outils spécifiquement liés à CommonJS

Même si NestJS fonctionne correctement, un script ou outil utilisé ailleurs dans le pipeline pourrait ne pas fonctionner.

3. Le support intégré des schémas standards change la logique de validation

L’une des ajouts les plus notables dans NestJS 12 est le support intégré pour les schémas standards.

Si vous avez passé du temps avec TypeScript récemment, il est probable que vous ayez rencontré des bibliothèques comme Zod, Valibot ou ArkType. Ces outils gèrent la validation en temps de exécution tout en s’intégrant parfaitement au contrôle de types de TypeScript.

Historiquement, NestJS s’appuyait sur des DTO basés sur des classes associés à class-validator. Ce modèle fonctionne toujours et n’est pas supprimé. NestJS 12 ajoute simplement une alternative.

Voici à quoi cela ressemble en pratique :

@Post()
create(
  @Body({
    schema: createUserSchema,
  })
  body: CreateUserDto,
) {
  return this.usersService.create(body);
}

Vous l’configurez ensuite de manière globale :

app.useGlobalPipes(
  new StandardSchemaValidationPipe(),
);

Avec cette approche, le schéma lui-même s’occupe de valider les requêtes entrantes. C’est particulièrement pratique si votre codebase définit déjà des schémas à l’aide de Zod ou d’une autre bibliothèque respectant la spécification Standard Schema.

4. Zod s’intègre plus directement à NestJS

Supposons que vous ayez déjà un schéma Zod défini de cette manière :

const createUserSchema = z.object({
  name: z.string().min(1),
  email: z.email(),
});

Plutôt que de dupliquer cette logique dans une couche de validation spécifique à NestJS, vous pouvez intégrer directement le schéma existant dans le traitement des requêtes.

Il en va de même pour les paramètres de route :

@Get(':id')
findOne(
  @Param('id', {
    schema: z.coerce
      .number()
      .int()
      .positive(),
  })
  id: number,
) {
  return this.usersService.findOne(id);
}

Cela réduit la logique redondante. Au lieu de conserver un ensemble de règles de validation pour le client et un autre pour le serveur, les équipes peuvent partager un seul schéma là où leur configuration le permet. De plus, ces schémas peuvent également servir à générer de la documentation OpenAPI.

5. Le schéma standard s’applique également aux réponses sortantes

La validation ne se limite pas à ce qui arrive en entrée — ce qui sort est également important.

Prenons le cas où une extrémité de réseau renvoie accidentellement quelque chose comme :

{
  "id": 1,
  "name": "John",
  "passwordHash": "..."
}

Techniquement, le gestionnaire a bien renvoyé un objet. Mais cet objet peut révéler plus d’informations que ce à quoi le contrat API était destiné.

Pour y remédier, NestJS 12 intègre StandardSchemaSerializerInterceptor, qui vérifie et reformate les données sortantes avant qu’elles n’atteignent le client.

Par exemple :

@UseInterceptors(
  StandardSchemaSerializerInterceptor,
)
@SerializeOptions({
  schema: userResponseSchema,
})
@Get(':id')
findOne(@Param('id') id: string) {
  return this.usersService.findOne(id);
}

Le résultat est une couverture de validation aux deux extrémités du cycle de requête :

Client
↓
Request
↓
Schema Validation
↓
Application
↓
Schema Serialization
↓
Response
↓
Client

Pour les services conçus principalement autour d’API, cette symétrie représente une amélioration significative.

6. Observabilité intégrée grâce à @nestjs/observe

NestJS 12 introduit également un package dédié à l’observabilité :

@nestjs/observe

Ce qui le distingue, c’est qu’il prend en compte la structure interne de NestJS. Un agent de surveillance typique ne verrait que quelque chose comme :

POST /users
200

En revanche, les outils propres à Nest peuvent reconnaître des constructions de niveau supérieur telles que des contrôleurs, des fournisseurs, des résolveurs GraphQL, des consommateurs de files d’attente, des tâches et des microservices.

L’instrumentation s’étend à plusieurs domaines, notamment HTTP, GraphQL, gRPC, les microservices, les consommateurs de files d’attente et les tâches cron.

L’objectif est de considérer l’observabilité comme un élément intégré au cycle de vie de l’application, et non comme quelque chose qui est ajouté en externe au niveau du serveur HTTP.

7. L’observabilité est un sujet qui devrait intéresser les équipes de QA

D’un point de vue des équipes de QA, cette couche d’observabilité mérite une attention particulière.

Les tests ne devraient pas s’arrêter dès que une API renvoie une réponse :

200 OK

Il est utile de comprendre ce qui s’est réellement passé pendant la génération de cette réponse.

Imaginons une requête qui circule dans le système de la manière suivante :

Request
↓
Controller
↓
Service
↓
Database
↓
External API
↓
Response

Si une appel prend trois secondes pour s’achever, un statut 200 seul ne suffit pas à donner une image complète de la situation.

Ce que l’on veut vraiment savoir, c’est où se sont écoulées ces trois secondes.

Les causes possibles incluent :

• des requêtes de base de données lentes
• des retards provenant d’une API externe
• du temps passé dans la logique de l’application

file d'attente des requêtes

tentatives de réessai inattendues

Les données d'observabilité fournissent aux équipes de QA et d’ingénierie une couche supplémentaire de preuves sur lesquelles travailler, permettant de relier les échecs des tests au comportement réel en production.

8. La validation des configurations passe au schéma standard

Gestion des configurations : un autre domaine qui fait l’objet d’une mise à jour.

Historiquement, de nombreuses applications NestJS comptaient sur Joi à cette fin :

ConfigModule.forRoot({
  validationSchema: schema,
});

Avec NestJS 12, la validation des configurations passe plutôt au schéma standard.

Voici à quoi cela ressemble dans la pratique :

ConfigModule.forRoot({
  validationSchema: z.object({
    NODE_ENV: z
      .enum([
        'development',
        'production',
        'test',
      ])
      .default('development'),

    PORT: z.coerce
      .number()
      .default(3000),
  }),
});

Joi n’a pas été abandonné — les projets existants peuvent continuer à l’utiliser, mais ils devront mettre à jour leur version vers Joi 18 ou ultérieure et déplacer tous les paramètres spécifiques à la bibliothèque sous :

validationOptions.libraryOptions

Cela fait partie d’une initiative plus large visant à créer une interface de schéma commune dans l’écosystème du framework.

9. Les routes conflictuelles peuvent désormais être détectées automatiquement

Il existe un piège subtil dans la conception de l’API qui est souvent difficile à repérer avant qu’il ne cause des problèmes.

Supposons que vous définissiez ces deux gestionnaires :

@Get(':id')
findOne() {}

@Get('me')
getCurrentUser() {}

En fonction de la manière dont les routes sont résolues et de l’ordre dans lequel elles sont déclarées, une requête vers :

/users/me

peut finir par correspondre au schéma :

/users/:id

au lieu d’atteindre le gestionnaire dédié /me comme prévu.

NestJS 12 ajoute une fonctionnalité de diagnostic optionnelle pour détecter ce type d’ambiguïté de route.

Vous l’activez comme ceci :

const app = await NestFactory.create(
  AppModule,
  {
    routeConflictPolicy: {
      duplicate: 'error',
      shadow: 'warn',
    },

    routeResolutionStrategy:
      'specificity',
  },
);

Cela permet aux développeurs de détecter proactivement des règles de routage ambiguës, plutôt que de les découvrir par hasard à travers une réponse API confuse plus tard.

10. Codes d’erreur que les machines peuvent réellement interpréter

Une petite modification supplémentaire ici peut s’avérer cruciale pour tout ce qui utilise votre API.

Prenons cette exception :

throw new BadRequestException(
  'Password is too weak',
);

if (message === 'Password is too weak') {
  ...
}

Cette approche est fragile, car la formulation peut changer.

Un contrat plus fiable consiste à utiliser plutôt un code d’erreur stable :

throw new BadRequestException(
  'Password is too weak',
  {
    errorCode: 'WEAK_PASSWORD',
  },
);

Le client peut alors vérifier ce code :

WEAK_PASSWORD

au lieu de dépendre d’une formulation exacte du message.

Cela devient encore plus important lorsque l’API a plusieurs utilisateurs, tels que :

• un frontend web
• une application mobile
• une API destinée aux partenaires
• des services internes

Tous peuvent s’appuyer sur le même identifiant d’erreur cohérent au lieu de parser du texte lisible par les humains.

Le journalisation structurée est améliorée

Les fonctionnalités de journalisation ont également été améliorées dans cette version.

Vous pouvez maintenant écrire quelque chose comme ceci :

logger.log(
  'User created',
  {
    userId: 1,
    email: 'foo@bar.com',
  },
);

L’argument objet est traité comme des données structurées associées à cette ligne de journal spécifique, et non simplement comme du texte supplémentaire à afficher.

Lorsque le mode de sortie JSON est activé, ces données structurées apparaissent sous la clé params, ou peuvent être intégrées directement dans l’entrée de journal en utilisant l’option flattenParams.

Cela est très important si vos journaux alimentent un système de surveillance ou d’observabilité. Au lieu d’émettre des chaînes de caractères simples qui doivent être analysées ultérieurement, votre application peut émettre des entrées structurées qui peuvent être recherchées et filtrées dès le départ.

Par exemple, une entrée de journal pourrait ressembler à ceci :

{
  "message": "User created",
  "params": {
    "userId": 1,
    "email": "foo@bar.com"
  }
}

Ce format est bien plus facile à interroger que de tenter d’extraire des champs à partir d’un message de texte brut.

La CLI a été entièrement réécrite

Un autre changement majeur dans cette version concerne une refonte complète de la CLI.

Son code a été déplacé vers ESM. Son ensemble de tests a été remplacé de Jest par Vitest. Une couverture bout en bout a été ajoutée pour les commandes CLI, et la structure interne des commandes a été refactorisée autour d’objets de contexte typés.

Rien de tout cela n’affecte nécessairement directement le code de votre application. Cependant, c’est un signe que les efforts de modernisation ne se limitent pas au runtime lui-même — les outils et le flux de travail des développeurs sont également mis à jour.

nest upgrade simplifie le parcours de migration

La CLI réécrite inclut une nouvelle commande :

nest upgrade

Avant d’appliquer quoi que ce soit, vous pouvez examiner ce qu’elle a l’intention de modifier :

Before running it, you can preview the changes:

Cela est précieux car une augmentation majeure de version touche souvent de nombreux détails de configuration petits et non liés entre eux. La commande d’upgrade peut gérer automatiquement les modifications techniques telles que :

• l’augmentation des versions des paquets @nestjs/*
• la mise à jour de la configuration webpack
• le remplacement de GraphQL Playground par GraphiQL
• l’ajustement du transport des abonnements GraphQL
• la mise à jour des paquets liés à NATS
• l’ajustement de l’utilisation de @nestjs/config
• la mise à jour des dépendances Jest
• la mise à jour des dépendances Joi

Lorsqu’elle est terminée, elle affiche un résumé de ce qui a été modifié automatiquement et de ce qui nécessite encore une vérification manuelle.

Les projets générés récemment partent de paramètres par défaut modernes

La création d’un projet entièrement nouveau avec NestJS 12 vous offre désormais un point de départ différent.

Les nouvelles configurations de monorepo utilisent par défaut Rspack comme outil de bundling. Les nouveaux projets emploient oxlint à la place d’ESLint. Vitest est désormais l’exécuteur de tests par défaut pour les projets basés sur ESM. Bun est également accepté comme option de gestionnaire de paquets, en plus des choix existants :

npm
yarn
pnpm

Rien de tout cela ne modifie rétroactivement les projets existants — cette distinction est importante. NestJS 12 définit simplement un standard plus moderne pour tout ce qui sera créé à l’avenir, tout en permettant aux applications déjà existantes de migrer à leur propre rythme.

Les configurations GraphQL nécessitent une certaine prudence

Si vous exécutez une application GraphQL, il y a des tâches de migration que vous ne devriez pas ignorer.

GraphiQL remplace désormais GraphQL Playground en tant qu’IDE par défaut. Plus important encore, le support pour :

subscriptions-transport-ws

a été complètement supprimé. Vous êtes censé passer à :

graphql-ws

Ces deux protocoles ne sont pas compatibles l’un avec l’autre au niveau du câblage. Cela signifie que modifier le mécanisme de transmission des abonnements dans votre backend n’est pas une modification uniquement liée au backend — tout élément qui consomme ces abonnements doit également être mis à jour et testé :

NestJS API
↓
GraphQL Subscription
↓
Web / Mobile Client

Mettre à jour une dépendance uniquement du côté serveur ne suffira pas pour que tout fonctionne de bout en bout.

Le support de NATS a également changé

Le framework remplace désormais le paquet nats par :

@nats-io/transport-node

Si votre application importe directement l’ancien paquet, vous devrez mettre à jour à la fois la dépendance et les instructions d’import correspondantes.

Il y a également des changements dans la manière dont les paquets sont gérés : les charges utiles sont désormais sérialisées sous forme de chaînes JSON, et tout déserialiseur personnalisé que vous avez écrit recevra l’objet de message NATS complet plutôt qu’une charge utile déjà analysée. Vous pouvez lire le contenu de la charge utile en utilisant :

msg.json()

Si les messages constituent une partie essentielle de votre système, c’est un aspect qui mérite d’être mentionné spécifiquement dans vos plans de tests d’intégration et de régression.

17. L’ordre des hooks de cycle de vie a changé

Un autre changement majeur est lié aux hooks de cycle de vie.

Dans NestJS 12, l’ordre d’exécution des hooks de cycle de vie dépend désormais de la position d’un composant dans l’arborescence.

Cela est important si votre application repose sur une séquence spécifique lors de :

• l’initialisation
• le démarrage
• l’arrêt
• la fermeture

Supposons qu’un service mette en ligne des ressources dans cet ordre :

Database
Queue
Cache
External API

Un autre service suppose que l’un de ces ressources est déjà disponible. Après la mise à niveau, vous devrez vérifier que cette supposition reste valable.

C’est précisément le type de changement qui ne se manifeste pas nécessairement comme une erreur de compilation. Votre projet peut se compiler sans erreurs tout en fonctionnant différemment en temps de exécution.

18. Autres changements importants à connaître

Quelques autres ajustements font partie de cette version.

NestJS 12 touche également :

• la structure des réponses d’erreur de validation
• la manière dont les exceptions gRPC sont gérées
• la correspondance de motifs par expression régulière dans Kafka
• les passerelles WebSocket au niveau de la requête
• les raisons indiquées en cas de déconnexion WebSocket
• les hooks avant requête pour les microservices
• le comportement de fermeture propre dans Express
• la manière dont l’adaptateur HTTP mappe les erreurs

La plupart des projets n’auront pas besoin de prendre en compte chacune de ces fonctionnalités. Mais là où votre application dépend réellement d’une d’entre elles, il est utile d’ajouter des tests de régression ciblés pour celle-ci.

19. Sur quoi le QA doit-il se concentrer après la mise à niveau ?

C’est sans doute la question la plus importante à répondre.

Vérifier que la mise à niveau d’un framework majeur s’est déroulée sans problème ne doit pas se limiter à l’exécution de :

npm test

En revanche, les tests doivent être divisés en domaines distincts.

API

Vérifier :

• l’authentification
• l’autorisation
• la validation
• les réponses aux erreurs
• la correspondance des routes
• la sérialisation des réponses

Configuration

Vérifier :

• les variables d’environnement obligatoires
• les valeurs invalides
• les valeurs par défaut
• la configuration de production
• la configuration de test

GraphQL

Lorsque cela est pertinent :

• requêtes
• mutations
• abonnements
• GraphiQL
• compatibilité des clients

Microservices

Lorsque cela est pertinent :

• NATS
• Kafka
• gRPC
• serialisation des messages
• retries
• Gestion des exceptions

Observabilité

Lorsque cette fonction est activée :

• traçages HTTP
• traçages GraphQL
• tâches en arrière-plan
• consommateurs de files d’attente
• erreurs
• tâches cron

Mise hors service

Vérifier :

• Gestion de SIGTERM
• requêtes en cours
• connexions à la base de données
• files d’attente
• travailleurs en arrière-plan

L’objectif n’est pas de répondre à :

"L’application démarre-t-elle ?"

Mais plutôt de répondre à :

"L’application continue-t-elle de fonctionner correctement dans tous les scénarios importants ?"

20. Ce que cette version signifie pour le travail de QA

Il existe une tendance plus large qui mérite d’être notée.

Les frameworks deviennent de plus en plus automatisés. La validation est en train de se standardiser. L’observabilité est intégrée directement. Les journaux deviennent structurés par défaut. Les conflits de routes peuvent être détectés automatiquement. Les outils de test gagnent en vitesse constamment.

Rien de tout cela ne supprime le besoin de QA. Cela modifie simplement les domaines où le QA apporte le plus de valeur.

Au lieu de se demander uniquement :

"Cet endpoint fonctionne-t-il ?"

Le QA doit de plus en plus se demander :

"Le contrat API est-il toujours correct ?" "Les échecs sont-ils observables ?" "Les permissions sont-elles correctement appliquées ?" "Les erreurs sont-elles lisible par une machine ?" "La sérialisation est-elle correcte ?" "l’application se remet-elle en état comme prévu ?" ">Cette mise à niveau modifie-t-elle le comportement existant ?"

Le framework peut automatiser certaines vérifications par lui-même. Mais une personne doit encore décider quels éléments méritent d’être vérifiés en premier lieu.

21. Une approche recommandée pour une migration vers NestJS 12

Au lieu de mettre à niveau directement l’environnement de production, commencez par vérifier votre environnement :

node --version

Vérifiez que vous êtes sur :

Node 20.19+

ou bien :

Node 22.12+

Ensuite, mettez à jour la CLI :

npm i -g @nestjs/cli@latest

Prévisualisez l’effet de la migration :

nest upgrade --dry-run

Examinez attentivement le résultat. Ensuite, appliquez-le :

nest upgrade

Après cela, exécutez :

npm test

en même temps que vos suites d’intégration et de test bout en bout.

Prêtez une attention particulière à toute fonctionnalité basée sur :

• GraphQL
• NATS
• vérification de la configuration
• tuyaux personnalisés
• hooks de cycle de vie
• Webpack
• Outils basés sur CommonJS

Chacun de ces domaines présente des considérations de migration qui méritent d’être vérifiées individuellement.

Considerations finales

NestJS 12 n’est pas simplement une question d’ajout d’une nouvelle fonctionnalité.

Celui-ci représente une étape vers l’alignement de NestJS avec l’orientation actuelle de l’écosystème Node.js et TypeScript.

ESM est désormais intégré à l’architecture même des paquets.

Standard Schema ouvre le framework aux bibliothèques de validation telles que Zod, Valibot, ArkType et d’autres.

Cet même écosystème de schémas peut également être utilisé pour la sérialisation.

L’observabilité est désormais liée de manière plus directe à la structure d’application propre à Nest.

La CLI a été reconstruite autour d’outils plus récents.

Rspack, Vitest, oxlint et Bun font désormais partie de l’ensemble qui caractérise une configuration moderne de NestJS.

Pendant ce temps, rien de tout cela ne force les applications existantes à changer absolument tout du jour au lendemain.

Vous pouvez continuer à utiliser la validation basée sur des classes.

Passer à Vitest ou oxlint n’est pas obligatoire immédiatement.

Cette flexibilité est sans doute l’aspect le plus pratique de cette version.

NestJS 12 met à jour le framework sans exiger que chaque application existante se modernise d’un coup.

Pour les développeurs, cela signifie plus de liberté pour choisir leur propre rythme.

Pour les ingénieurs QA, cela signifie une autre mise à jour majeure du framework qui doit être vérifiée — non seulement au niveau du code, mais aussi en ce qui concerne les API, les intégrations, l’observabilité, la configuration et le comportement réel en production.

C’est précisément là que les mises à jour de framework deviennent intéressantes.

Augmenter le numéro de version dans package.json est la partie facile.

Ce qui compte vraiment, c’est que l’application continue de fonctionner comme ceux qui s’y fient l’anticipent.

Lectures complémentaires

• Partager un même schéma Zod entre votre frontend React et votre backend Node — Découvrez comment un seul schéma Zod peut valider les formulaires React, les réponses API, les corps de requête Express et les variables d’environnement tout en générant des types TypeScript correspondants.

Le compilateur Go de TypeScript et l’exécution native : un guide de migration — Découvrez comment le compilateur basé sur Go de TypeScript et l’exécution native via Node.js affecteront les bases de code React et Next.js, ainsi que ce qu’il convient de corriger dans votre tsconfig dès maintenant.