Startseite / Artikel / NestJS 12-Migrationsanleitung: ESM, Standard-Schema und Überwachungsfunktionen

NestJS Node.js TypeScript ESM Zod Observability

NestJS 12-Migrationsanleitung: ESM, Standard-Schema und Überwachungsfunktionen

Diese Anleitung erläutert die wichtigsten Änderungen in NestJS 12 – ESM-Pakete, Standard-Schema-Validierung, eingebaute Überwachungsfunktionen sowie Aktualisierungen der CLI – und zeigt, wie man sicher migrieren kann.

3328 Wörter

NestJS 12 ist da, und im Gegensatz zu typischen großen Versionserhöhungen dreht sich diese Veröffentlichung nicht um eine einzige herausragende Funktion.

Sie betrifft stattdessen gleich mehrere Bereiche des NestJS-Ökosystems und aktualisiert sie entsprechend dem heutigen Stand der Backend-Entwicklung.

Zu den bemerkenswertesten Updates gehören:

Nest-Pakete werden nun als ESM bereitgestellt
Validierung basierend auf Standard Schema
Serialisierung basierend auf Standard Schema
Eingebaute Überwachungsfunktionen über @nestjs/observe
Eine neu geschriebene NestJS CLI
Rspack-Unterstützung für neue Monorepo-Einrichtungen
Vitest und oxlint sind in neuen Projekten standardmäßig enthalten
Intelligenterer Erkennung von konflikten Routen
Fehlercodes, die von Tools verarbeitet werden können
Gestrukturierte, maschinenfreundliche Protokollierung

Falls Sie bereits eine NestJS-Codebasis betreiben, gibt es einen Aspekt, der sofort alle Bedenken beseitigen sollte:

Es ist nicht notwendig, Ihre Anwendung auf ESM umzustellen, nur weil NestJS 12 selbst als ESM bereitgestellt wird.

Diese Tatsache verwandelt das, was wie ein umstürzender Update erscheinen könnte, in etwas, das Sie in Ihrem eigenen Tempo übernehmen können.

NestJS 12 konzentriert sich auf die Aktualisierung des Frameworks

NestJS wird weit verbreitet eingesetzt, um gut organisierte Backend-Dienste auf Basis von Node.js und TypeScript zu entwickeln.

Seine Gesamtstruktur hat sich nicht geändert und bleibt für alle erkennbar, die es bereits verwendet haben:

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:

Was sich geändert hat, ist die umgebende Node.js-Landschaft.

Die Adoption von ESM wächst weiterhin im gesamten Ökosystem.

Schemabibliotheken wie Zod gewinnen an Bedeutung.

Neue, schnellere Bundler ersetzen die alten Build-Tools.

Die Beobachtbarkeit wird im Entwicklungsprozess zunehmend als zentrales Anliegen betrachtet und nicht erst nach dem Veröffentlichen eines Services hinzugefügt.

NestJS 12 holt im Grunde alle diese Entwicklungen gleichzeitig auf.

Bemerkenswert ist jedoch, dass nichts davon bestimmt, dass bestehende Anwendungen bereits am ersten Tag alles übernehmen müssen.

1. Kern-Nest-Pakete werden nun als ESM bereitgestellt

Vielleicht ist die auffälligste Veränderung in dieser Version, dass Nests Kernpakete nun im ESM-Format veröffentlicht werden.

Falls Ihr Projekt auf CommonJS basiert, könnte das den Eindruck erwecken, es sei notwendig, alles umzuschreiben.

Zum Glück unterstützen moderne Versionen von Node.js require(esm).

In der Praxis bedeutet das, dass die meisten CommonJS-Anwendungen weiterhin wie bisher laufen können, ohne eine vollständige Umwandlung in ESM.

Zum Beispiel funktioniert diese Zeile weiterhin genauso wie zuvor:

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

Es ist nicht erforderlich, es wie folgt umzuschreiben:

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

Trotzdem erhöht NestJS 12 die minimale erforderliche Node.js-Version.

Einschließlich der Notwendigkeit, eine der folgenden Versionen zu verwenden:

Node.js 20.19+
or
Node.js 22.12+

Node.js 21.x wird ausdrücklich nicht unterstützt.

Bevor Sie die NestJS-Abhängigkeiten anfassen, überprüfen Sie daher, welche Node-Version Sie verwenden:

node --version

Die Überprüfung dieses Aspekts frühzeitig in Ihrem CI/CD-Pipeline ist ebenfalls eine sinnvolle Vorsichtsmaßnahme.

2. Der Wechsel zu ESM ist eine Wahl, keine Pflicht

Dieser Punkt erfordert besondere Betonung für Teams, die bestehende Projekte warten.

Hier finden zwei getrennte Migrationsprozesse statt.

NestJS selbst wandelt seine Pakete in ESM um.

Ihre Anwendung ist jedoch nicht verpflichtet, dies unverzüglich nachzuahmen.

Anders ausgedrückt, diese Konfiguration ist völlig gültig:

Existing CommonJS Application
↓
NestJS 12
↓
Continue running CommonJS

anstatt gezwungen zu werden, es so zu machen:

CommonJS
↓
Rewrite everything
↓
ESM
↓
NestJS 12

Trotzdem kann eine maßgeschneiderte Tooling-Lösung für Ihr Projekt immer noch zu Problemen führen.

Es lohnt sich, Folgendes nochmals zu überprüfen:

maßgeschneiderte Bootstrap-Skripte
Build-Pipelines
Testausführer
Bundler-Konfigurationen
nicht-standardmäßige Importmuster
Tooling, das speziell an CommonJS gebunden ist

Auch wenn NestJS selbst einwandfrei funktioniert, könnte ein Skript oder Tool, auf das Sie an anderer Stelle in der Pipeline angewiesen sind, Probleme bereiten.

3. Die Unterstützung für Standard Schema verändert die Validierungslogik

Zu den bemerkenswertesten Neuerungen in NestJS 12 gehört die eingebaute Unterstützung für Standard Schema.

Falls Sie in letzter Zeit mit TypeScript gearbeitet haben, sind Sie wahrscheinlich auf Bibliotheken wie Zod, Valibot oder ArkType gestoßen. Diese Tools kümmern sich um die Laufzeitvalidierung und integrieren sich dabei nahtlos in die Typüberprüfung von TypeScript.

Historisch gesehen setzte NestJS auf klassenbasierte DTOs in Kombination mit class-validator. Dieses Muster funktioniert weiterhin und wird nicht entfernt. NestJS 12 bietet lediglich einen alternativen Ansatz.

So sieht das in der Praxis aus:

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

Dann wird es global konfiguriert:

app.useGlobalPipes(
  new StandardSchemaValidationPipe(),
);

Mit dieser Lösung übernimmt das Schema selbst die Validierung der eingehenden Anfragen. Dies ist besonders praktisch, wenn Ihre Codebasis bereits Schemata mit Zod oder einer anderen Bibliothek definiert hat, die den Standard Schema-Spezifikationen folgt.

4. Zod integriert sich direkter mit NestJS

Nehmen wir an, Sie haben bereits ein Zod-Schema wie folgt definiert:

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

Anstatt diese Logik in eine separate, nestjs-spezifische Validierungs Schicht zu kopieren, können Sie das vorhandene Schema direkt in den Anfrageablauf einbinden.

Das Gleiche gilt für Route-Parameter:

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

Dadurch wird wiederholende Logik reduziert. Anstatt ein Set an Validierungsregeln für den Client und ein anderes für den Server zu verwenden, können Teams ein einziges Schema teilen, sofern ihre Konfiguration dies zulässt. Als Bonus können diese Schemata auch zur Erstellung von OpenAPI-Dokumentationen genutzt werden.

5. Das Standard-Schema gilt auch für ausgehende Antworten

Die Validierung beschränkt sich nicht nur auf das, was eingehend wird – auch das, was ausgehend gesendet wird, ist wichtig.

Betrachten Sie einen Fall, in dem ein Endpunkt versehentlich etwas wie Folgendes zurückgibt:

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

Technisch gesehen hat der Handler tatsächlich ein Objekt zurückgegeben. Doch dieses Objekt kann mehr offenbaren, als im API-Vertrag vorgesehen war.

Um dies zu beheben, bietet NestJS 12 den StandardSchemaSerializerInterceptor an, der die ausgehenden Daten vor deren Erreichen des Clients überprüft und umformt.

Zum Beispiel:

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

Das Ergebnis ist eine Überprüfung der Validierung in beiden Phasen des Anfragenzyklus:

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

Für Dienste, die hauptsächlich um APIs herum aufgebaut sind, stellt diese Symmetrie eine bedeutende Verbesserung dar.

6. Integrierte Überwachbarkeit durch `@nestjs/observe`

NestJS 12 führt außerdem ein spezielles Paket für die Überwachbarkeit ein:

@nestjs/observe

Was es auszeichnet, ist, dass es die interne Struktur von NestJS kennt. Ein typischer Überwachungsagent würde nur etwas wie Folgendes erkennen:

POST /users
200

Die eigenen Tools von Nest hingegen können höherwertige Konstrukte wie Controller, Provider, GraphQL-Resolver, Warteschlangenverarbeiter, Jobs und Microservices erkennen.

Die Instrumentierung erstreckt sich auf mehrere Bereiche, darunter HTTP, GraphQL, gRPC, Microservices, Warteschlangenverarbeiter und Cron-Jobs.

Ziel ist es, die Beobachtbarkeit als etwas zu betrachten, das in den Lebenszyklus der Anwendung integriert ist, anstatt als etwas, das extern auf der Ebene des HTTP- Servers hinzugefügt wird.

7. Beobachtbarkeit ist etwas, worum sich QA kümmern sollte

Von der Sichtweise aus QA verdient diese Schicht der Beobachtbarkeit Aufmerksamkeit.

Die Tests sollten nicht sofort enden, sobald eine API eine Antwort zurücksendet:

200 OK

Es ist nützlich, zu verstehen, was tatsächlich während der Erstellung dieser Antwort geschah.

Betrachten Sie eine Anfrage, die so durch das System fließt:

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

Falls ein Aufruf drei Sekunden zur Bearbeitung benötigt, sagt der Status 200 allein nicht die ganze Wahrheit.

Was man wirklich wissen möchte, ist, wo diese drei Sekunden verbracht wurden.

Mögliche Ursachen sind:

langsame Datenbankabfragen
Verzögerungen durch eine externe API
Zeit, die in der Anwendungslogik verbracht wird

Warteschlangen-Backlog

Unerwartete Wiederholungsversuche

Observabilitätsdaten liefern den QA- und Engineering-Teams eine zusätzliche Evidenzbasis, die dabei hilft, Testfehler mit dem tatsächlichen Verhalten in der Produktion in Verbindung zu bringen.

8. Konfigurationsvalidierung wechselt auf Standard Schema

Auch die Handhabung von Konfigurationen wird überarbeitet.

Früher verließen sich viele NestJS-Anwendungen dafür auf Joi:

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

Mit NestJS 12 wechselt die Konfigurationsvalidierung stattdessen zu Standard Schema.

So sieht das in der Praxis aus:

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

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

Joi wird nicht entfernt – bestehende Projekte können es weiterhin verwenden, müssen jedoch auf Joi 18 oder neuer upgraden und alle bibliotheksspezifischen Einstellungen unter folgendem Pfad platzieren:

validationOptions.libraryOptions

Das ist Teil eines umfassenderen Bemühens um eine gemeinsame Schema-Schnittstelle im gesamten Ökosystem des Frameworks.

9. Kollidierende Routen können nun automatisch erkannt werden

Es gibt eine subtile Falle in der API-Design, die oft erst dann auffällt, wenn sie Probleme verursacht.

Nehmen wir an, Sie definieren diese beiden Handler:

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

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

Je nachdem, wie die Routen gelöst werden und in welcher Reihenfolge sie deklariert sind, kann eine Anfrage an:

/users/me

letztendlich zum Muster passen:

/users/:id

anstatt wie beabsichtigt auf den speziellen /me-Handler zuzugreifen.

NestJS 12 fügt eine optional einsetzbare Diagnosefunktion hinzu, um diese Art von Routenunklarheit aufzudecken.

Sie aktivieren sie wie folgt:

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

    routeResolutionStrategy:
      'specificity',
  },
);

Dadurch können Entwickler unklare Routing-Regeln proaktiv erkennen, anstatt später durch eine verwirrende API-Antwort darauf zu stoßen.

10. Fehlercodes, die Maschinen tatsächlich parsen können

Noch eine kleine Ergänzung hier könnte für alle, die Ihre API nutzen, von großer Bedeutung sein.

Nehmen wir diese Ausnahme:

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

Ein Frontend-Entwickler könnte versucht sein, direkt auf den Nachrichtentext abzustimmen:

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

Der Ansatz ist anfällig, da die Formulierungen sich ändern können.

Ein robusterer Ansatz besteht darin, stattdessen einen stabilen Fehlercode hinzuzufügen:

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

Dann kann der Client darauf prüfen:

WEAK_PASSWORD

anstatt von der genauen Formulierung der Nachricht abhängig zu sein.

Dies ist umso wichtiger, wenn eine API mehrere Nutzer hat, wie zum Beispiel:

eine Web-Oberfläche
eine Mobile-App
eine API für Partner
interne Dienste

Sie alle können sich auf denselben konsistenten Fehleridentifikator verlassen, anstatt menschenlesbaren Text zu analysieren.

Gestrukturiertes Logging wird verbessert

Auch bei der Protokollierung gibt es in dieser Version Verbesserungen.

Sie können jetzt etwas wie folgt schreiben:

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

Das Objektargument wird als strukturierte Daten betrachtet, die an diese spezielle Protokollierungslinie angehängt sind, anstatt nur als zusätzlicher Text zum Ausgeben.

Wenn der JSON-Ausgabemodus aktiviert ist, werden diese strukturierten Daten unter dem Schlüssel params angezeigt, oder sie können mithilfe der Option flattenParams direkt in die Protokollierungseinträge eingefügt werden.

Dies ist besonders wichtig, wenn Ihre Protokolle in einen Überwachungs- oder Observabilitätsprozess fließen. Anstatt einfacher Zeichenketten auszugeben, die später noch analysiert werden müssen, kann Ihre Anwendung strukturierte Einträge erzeugen, die von Anfang an such- und filterbar sind.

Zum Beispiel könnte ein Protokollierungseintrag so aussehen:

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

Diese Formatierung lässt sich weitaus leichter abfragen als das Auslesen von Feldern aus einer reinen Textnachricht.

Die CLI wurde neu entwickelt

Eine weitere bedeutende Änderung in dieser Version ist eine vollständige Überarbeitung der CLI.

Ihr Codebasis wurde auf ESM verlegt. Die Testsuite wechselte von Jest zu Vitest. Für die CLI-Befehle wurde eine End-to-End-Coverage hinzugefügt, und die interne Befehlssyntax wurde um typisierte Kontextobjekte herum refaktorisiert.

Davon betrifft nichts unbedingt Ihren Anwendungscode direkt. Es ist jedoch ein Zeichen dafür, dass die Modernisierungsbemühungen nicht nur auf den Laufzeitumfang beschränkt sind – auch die Tools und der Entwicklungsprozess werden auf den neuesten Stand gebracht.

`nest upgrade` vereinfacht den Migrationsweg

Die neu entwickelte CLI bringt einen neuen Befehl mit sich:

nest upgrade

Bevor Sie etwas anwenden, können Sie überprüfen, was geändert werden soll:

Before running it, you can preview the changes:

Dies ist von großer Bedeutung, da ein Major-Upgrade oft viele kleine, unzusammenhängende Konfigurationsdetails betrifft. Der Upgrade-Befehl kann automatisch mechanische Änderungen wie folgende durchführen:

Aufwertung der Versionen der @nestjs/*-Pakete
Aktualisierung der webpack-Konfiguration
Austausch von GraphQL Playground durch GraphiQL
Anpassung des Transportmechanismus für GraphQL-Abonnements
Aktualisierung der mit NATS verbundenen Pakete
Anpassung der Verwendung von @nestjs/config
Aktualisierung der Jest-Abhängigkeiten
Aktualisierung der Joi-Abhängigkeiten

Sobald die Aktualisierung abgeschlossen ist, wird eine Zusammenfassung ausgegeben, was automatisch geändert wurde und was noch manuell überprüft werden muss.

Frisch generierte Projekte starten mit modernen Standardeinstellungen

Das Erstellen eines völlig neuen Projekts mit NestJS 12 bietet nun einen anderen Ausgangspunkt.

Neue Monorepo-Einrichtungen verwenden standardmäßig Rspack als Bundler. Neue Projekte nutzen oxlint anstelle von ESLint. Vitest ist nun der Standard-Testlaufzeitmechanismus für auf ESM basierende Projekte. Bun wird ebenfalls als Paketverwaltungsoption neben den bestehenden Optionen akzeptiert:

npm
yarn
pnpm

Das ändert nichts an bestehenden Projekten – dieser Unterschied ist wichtig. NestJS 12 legt einfach eine modernere Grundlage für zukünftig erstellte Anwendungen fest, während bestehende Anwendungen in ihrem eigenen Tempo migrieren können.

GraphQL-Einrichtungen erfordern Sorgfalt

Falls Sie eine GraphQL-Anwendung betreiben, gibt es Migrationsarbeiten, die Sie nicht überspringen sollten.

GraphiQL ersetzt nun GraphQL Playground als Standard-IDE. Noch wichtiger ist, dass die Unterstützung für:

subscriptions-transport-ws

gänzlich entfernt wurde. Von Ihnen wird erwartet, dass Sie auf:

graphql-ws

Diese beiden Protokolle sind auf der Übertragungsebene nicht kompatibel. Das bedeutet, dass eine Änderung des Abonnements-Transports im Backend keine reinige Backend-Änderung ist – alles, was diese Abonnements nutzt, muss ebenfalls aktualisiert und getestet werden:

NestJS API
↓
GraphQL Subscription
↓
Web / Mobile Client

Allein die Aktualisierung einer Abhängigkeit auf der Serverseite reicht nicht aus, um eine funktionierende End-zu-End-Kommunikation zu gewährleisten.

Auch die NATS-Unterstützung wurde verschoben

Das Framework ersetzt nun das nats-Paket durch:

@nats-io/transport-node

Falls Ihre Anwendung das alte Paket direkt importiert, müssen Sie sowohl die Abhängigkeit als auch die entsprechenden Importanweisungen aktualisieren.

Auch die Handhabung der Pakete hat sich geändert: Die Payloads werden nun als JSON-Strings serialisiert, und jeder von Ihnen geschriebene benutzerdefinierte Deserializer erhält das vollständige NATS-Nachrichtenobjekt anstelle eines bereits vorverarbeiteten Payloads. Sie können den Inhalt des Payloads mit folgendem Code lesen:

msg.json()

Falls die Nachrichtenübertragung ein zentraler Bestandteil Ihres Systems ist, handelt es sich um einen Bereich, den Sie in Ihren Integrationstest- und Regressionstestplänen ausdrücklich erwähnen sollten.

17. Die Reihenfolge der Lifecycle-Hooks hat sich geändert

Es gibt eine weitere brisante Änderung im Zusammenhang mit den Lifecycle-Hooks.

In NestJS 12 hängt die Reihenfolge, in der die Lifecycle-Hooks ausgelöst werden, nun davon ab, wo sich ein Komponente in der Hierarchie befindet.

Dies ist wichtig, wenn Ihre Anwendung auf einer bestimmten Abfolge während folgender Vorgänge angewiesen ist:

Initialisierung
Startvorgang
Ausstiegsvorgang
Zerstörung

Nehmen wir an, ein Service stellt Ressourcen in dieser Reihenfolge online:

Database
Queue
Cache
External API

Ein anderes Service-Modul geht davon aus, dass eine dieser Ressourcen bereits verfügbar ist. Nach dem Upgrade sollten Sie überprüfen, ob diese Annahme weiterhin zutrifft.

Genau dieser Art von Änderung zeigt sich nicht unbedingt als Kompilierfehler. Ihr Projekt kann fehlerfrei kompiliert werden und dennoch zur Laufzeit anders funktionieren.

18. Weitere Änderungen, die man kennen sollte

Mehrere weitere Anpassungen sind Teil dieser Version.

NestJS 12 betrifft außerdem:

die Struktur der Antworten auf Validierungsfehler
die Handhabung von gRPC-Exzeptionen
das Mustererkennungsverhalten von Kafka mit regulären Ausdrücken
WebSocket-Gateways im Anfragescope
die Gründe, die bei WebSocket-Verbindungsabbrüchen angezeigt werden
Vor-Anfrage-Hooks für Microservices
einen sanften Abstellvorgang in Express
die Art und Weise, wie der HTTP-Adapter Fehler abbildet

Die meisten Projekte werden nicht auf alle dieser Funktionen zurückgreifen. Doch wo Ihre Anwendung tatsächlich von einer dieser Funktionen abhängt, lohnt es sich, gezielte Regressionstests dafür hinzuzufügen.

19. Auf was sollte sich die QA nach dem Upgrade konzentrieren?

Das ist wohl die wichtigste Frage, die beantwortet werden muss.

Die Bestätigung, dass ein großer Framework-Upgrade reibungslos verlaufen ist, sollte nicht allein auf dem Ausführen folgender Schritte beruhen:

npm test

Stattdessen sollte der Test in verschiedene Bereiche unterteilt werden.

API

Überprüfen Sie:

Authentifizierung
Berechtigung
Validierung
Fehlerantworten
Route-Abgleich
Serialisierung der Antwort

Konfiguration

Überprüfen Sie:

Notwendige Umgebungsvariablen
Ungültige Werte
Standardwerte
Produktionskonfiguration
Testkonfiguration

GraphQL

Wo relevant:

Anfragen
Mutationen
Abonnements
GraphiQL
Klientenkompatibilität

Mikrodienste

Wo relevant:

NATS
Kafka
gRPC
Serialisierung von Nachrichten
Wiederholungsversuche
Fehlerbehandlung

Beobachtbarkeit

Falls aktiviert:

HTTP-Spuren
GraphQL-Spuren
Hintergrundaufgaben
Warteschlangenverarbeiter
Fehler
Cron-Aufgaben

Ausstieg

Überprüfen:

Behandlung von SIGTERM
Aktive Anfragen
Datenbankverbindungen
Warteschlangen
Hintergrundprozesse

Ziel ist es nicht, folgende Frage zu beantworten:

"Startet die Anwendung?"

Sondern folgende Frage zu beantworten:

"Verhält sich die Anwendung weiterhin korrekt an allen wichtigen Grenzfällen?"

20. Was diese Version für die QA-Arbeit bedeutet

Es gibt einen breiteren Trend, der Beachtung verdient.

Frameworks werden immer automatisierter. Die Validierung wird standardisiert. Die Überwachbarkeit wird direkt integriert. Logs sind standardmäßig strukturiert. Routenkonflikte können automatisch erkannt werden. Testwerkzeuge werden immer schneller.

Nichts davon beseitigt den Bedarf an QA. Es verschiebt lediglich, wo QA den größten Wert schafft.

Anstatt nur zu fragen:

">Funktioniert dieser Endpunkt?"

Muss QA zunehmend fragen:

">Ist der API-Vertrag immer noch korrekt?" ">Sind Fehler erkennbar?" ">Werden Berechtigungen ordnungsgemäß durchgesetzt?" ">Sind Fehler maschinenlesbar?" ">Ist die Serialisierung korrekt?" ">Kommt die Anwendung wieder in Ordnung, wie es sein sollte?" ">Verändert dieses Upgrade das bestehende Verhalten?"

Das Framework kann bestimmte Überprüfungen selbst automatisieren. Doch eine Person muss trotzdem entscheiden, was überhaupt geprüft werden sollte.

21. Ein vorgeschlagener Weg bei einer NestJS 12-Migration

Anstatt die Produktion direkt zu aktualisieren, sollten Sie zunächst Ihre Umgebung überprüfen:

node --version

Stellen Sie sicher, dass Sie auf folgendem Stand sind:

Node 20.19+

oder:

Node 22.12+

Danach aktualisieren Sie die CLI:

npm i -g @nestjs/cli@latest

Sehen Sie sich an, was die Migration bewirken würde:

nest upgrade --dry-run

Gehen Sie sorgfältig die Ausgabe durch. Wenden Sie sie anschließend an:

nest upgrade

Danach führen Sie aus:

npm test

zusammen mit Ihren Integrationstests und End-to-End-Tests.

Achten Sie besonders auf alle Funktionalitäten, die auf folgenden Elementen basieren:

GraphQL
NATS
Konfigurationsvalidierung
Custom-Pipes
Lifecycle-Hooks
Webpack
CommonJS-basierte Werkzeuge

Jeder dieser Bereiche erfordert Migrationsüberlegungen, die einzeln geprüft werden sollten.

Fazit

NestJS 12 ist nicht einfach nur die Hinzufügung einer weiteren Funktion.

Es stellt einen Schritt dar, um NestJS mit der aktuellen Entwicklungslinie des Node.js- und TypeScript-Ecosystems in Einklang zu bringen.

ESM ist nun direkt in die Paketarchitektur integriert.

Standard Schema eröffnet das Framework für Bibliotheken wie Zod, Valibot, ArkType und andere Validierungswerkzeuge.

Das gleiche Schema-Ökosystem kann auch zur Serialisierung verwendet werden.

Die Beobachtbarkeit ist nun enger mit der eigenen Anwendungsstruktur von Nest verbunden.

Die CLI wurde um neuere Werkzeuge herum neu konstruiert.

Rspack, Vitest, oxlint und Bun gehören nun zu den Bestandteilen einer modernen NestJS-Einrichtung.

Gleichzeitig zwingt nichts davon bestehende Anwendungen dazu, über Nacht alles zu ändern.

Sie können weiterhin CommonJS verwenden.

Sie können weiterhin auf klassenbasierte Validierung setzen.

Der Wechsel zu Vitest oder oxlint ist nicht sofort erforderlich.

Diese Flexibilität ist wohl der praktischste Aspekt dieser Version.

NestJS 12 bringt das Framework auf den neuesten Stand, ohne zu verlangen, dass jede bestehende Anwendung sofort modernisiert wird.

Für Entwickler bedeutet das mehr Freiraum, in ihrem eigenen Tempo voranzukommen.

Für QA-Engineer bedeutet das wieder einen großen Framework-Upgrade, das überprüft werden muss – nicht nur auf Codeebene, sondern auch in Bezug auf APIs, Integrationen, Überwachungsmöglichkeiten, Konfiguration sowie das tatsächliche Verhalten in der Produktion.

Darum werden Framework-Updates gerade so interessant.

Die Erhöhung der Versionnummer in package.json ist der einfache Teil.

Wirklich wichtig ist, ob die Anwendung weiterhin so funktioniert, wie die davon Abhängigen es erwarten.