Przewodnik migracji do NestJS 12: ESM, Standard Schema i możliwość obserwacji

NestJS 12 już jest dostępny, a w odróżnieniu od typowych dużych aktualizacji, ta wersja nie koncentruje się na jednej kluczowej nowości.

Zamiast tego dotyka kilku aspektów ekosystemu NestJS jednocześnie, aktualizując je zgodnie z obecnym standardem rozwoju backendu.

Do najważniejszych ulepszeń należą:

• Pakiety Nest teraz dystrybuowane jako ESM
• Walidacja oparta na Standard Schema
• Serializacja oparta na Standard Schema
• Wbudowana możliwość obserwacji poprzez @nestjs/observe
• Ponownie napisany interfejs CLI NestJS
• Obsługa Rspack dla nowych konfiguracji monorepo
• Vitest i oxlint dostępne domyślnie w nowych projektach
• Mądrzejsze wykrywanie sprzecznych tras
• Kody błędów, które narzędzia mogą analizować
• Ustrukturyzowane, łatwe do przetwarzania przez maszyny logi

Jeśli już zarządzasz bazą kodu NestJS, istnieje jeden szczegół, który powinien natychmiast rozwiać wszelkie obawy:

Nie jest konieczne przenoszenie Twojego aplikacji na ESM tylko dlatego, że sam NestJS 12 jest dostarczany w formacie ESM.

To jedno faktyczne założenie zamienia to, co mogłoby wyglądać na zakłócającą aktualizację, w coś, co możesz wdrożyć we własnym tempie.

NestJS 12 skupia się na aktualizacji frameworka

NestJS jest powszechnie używany do tworzenia dobrze zorganizowanych usług backendowych w oparciu o Node.js i TypeScript.

Jego ogólna struktura nie uległa zmianie i pozostaje rozpoznawalna dla wszystkich, którzy go wcześniej używali:

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:

Zmienił się natomiast otaczający ekosystem Node.js.

Adopcja ESM stale rośnie w całym ekosystemie.

Biblioteki do tworzenia schematów, takie jak Zod, zyskują na popularności.

Nowocześniejsze, szybsze narzędzia do pakowania zastępują stare narzędzia budujące.

Obserwowalność jest coraz częściej traktowana jako kwestia najwyższej wagi podczas rozwoju, a nie czymś, co dodaje się później po wypuszczeniu usługi.

NestJS 12 w zasadzie nadąża za wszystkimi tymi trendami jednocześnie.

Warto zauważyć, że nic z tego nie zmusza istniejących aplikacji do przyjęcia wszystkiego od razu.

1. Podstawowe pakiety Nest są teraz dostarczane w formacie ESM

Po prawdzie najbardziej widoczną zmianą w tym wydaniu jest to, że podstawowe pakiety Nest są teraz publikowane w formacie ESM.

Jeśli twój projekt jest zbudowany na CommonJS, może to brzmieć tak, jakby wymagało to dużej przeróbki.

Na szczęście nowoczesne wersje Node.js obsługują require(esm).

W praktyce oznacza to, że większość aplikacji opartych na CommonJS może nadal działać bez zmian, bez konieczności pełnej konwersji na ESM.

Naprzимер, ta linia nadal działa dokładnie tak samo jak wcześniej:

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

Nie jest wymagane, abyś to przepisał w następujący sposób:

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

Mimo to NestJS 12 faktycznie podnosi minimalną wersję Node.js, która jest potrzebna.

Konkretnie będziesz potrzebował jednej z następujących wersji:

Node.js 20.19+
or
Node.js 22.12+

Node.js 21.x jest wyraźnie nieobsługiwany.

Dlatego zanim zajmiesz się zależnościami NestJS, sprawdź, jaką wersję Node.js używasz:

node --version

Sprawdzenie tego we wczesnym etapie procesu CI/CD to również rozsądna środek ostrożności.

2. Przejście na ESM to wybór, a nie wymóg

To zagadnienie wymaga szczególnej uwagi ze strony zespołów utrzymujących istniejące projekty.

Tutaj zachodzą dwie oddzielne migracje.

Sam NestJS przechodzi na format ESM dla swoich pakietów.

Jednak twoja aplikacja nie jest zobowiązana do natychmiastowego podążania za tym krokiem.

Innymi słowy, taka konfiguracja jest w pełni dopuszczalna:

Existing CommonJS Application
↓
NestJS 12
↓
Continue running CommonJS

zamiast być zmuszanym do:

CommonJS
↓
Rewrite everything
↓
ESM
↓
NestJS 12

Mimo to, dostosowane narzędzia do projektu mogą nadal powodować problemy.

Warto to sprawdzić ponownie:

• spersonalizowane skrypty Bootstrap
• procesy budowania aplikacji
• narzędzia do testowania
• konfiguracja bundlera
• niestandardowe wzory importowania
• narzędzia powiązane wyłącznie z CommonJS

Nawet jeśli sam NestJS działa poprawnie, skrypt lub narzędzie, od którego korzystasz w innych częściach procesu, może mieć problemy.

3. Standardowe wsparcie schematów zmienia zasady walidacji

Jedną z najważniejszych nowości w NestJS 12 jest wbudowane wsparcie dla Standard Schema.

Jeśli ostatnio pracowałeś z TypeScript, prawdopodobnie spotkałeś się z bibliotekami takimi jak Zod, Valibot lub ArkType. Te narzędzia zajmują się walidacją w czasie wykonywania, jednocześnie łącząc się bez problemów z mechanizmem sprawdzania typów w TypeScript.

Historcznie NestJS opierał się na DTO-opartych na klasach w połączeniu z class-validator. Ten model nadal działa i nie jest usuwany. NestJS 12 po prostu dodaje alternatywną metodę.

Oto jak to wygląda w praktyce:

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

Następnie konfiguruje się to na poziomie globalnym:

app.useGlobalPipes(
  new StandardSchemaValidationPipe(),
);

Gdy to jest już wdrożone, sama szablona przejmuje zadanie walidacji przychodzących żądań. Jest to szczególnie przydatne, jeśli w Twojej bazie kodu już zdefiniowano szablony za pomocą Zod lub innej biblioteki, która spełnia specyfikację Standard Schema.

4. Zod łączy się bardziej bezpośrednio z NestJS

Załóżmy, że masz już zdefiniowaną szablonę Zod w ten sposób:

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

Zamiast kopiować tę logikę do oddzielnego warstwy walidacji specyficznej dla NestJS, można bezpośrednio włączyć istniejącą szablonę do obszaru żądania.

To samo dotyczy parametrów trasy:

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

To zmniejsza liczbę powtarzających się elementów logiki. Zamiast utrzymywać jeden zestaw reguł walidacji dla klienta i inny dla serwera, zespoły mogą dzielić się jednym schematem tam, gdzie to pozwala ich konfiguracja. Jako dodatkową zaletę, te schematy mogą być również wykorzystywane do generowania dokumentacji OpenAPI.

5. Standardowy schemat dotyczy również odpowiedzi wysyłanych

Walidacja nie ogranicza się tylko do tego, co przychodzi — to, co jest wysyłane, również ma znaczenie.

Rozważmy przypadek, gdy punkt końcowy przypadkowo zwraca coś takiego jak:

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

Technicznie rzecz biorąc, obsługa rzeczywiście zwróciła obiekt. Jednak ten obiekt może ujawniać więcej informacji, niż przewidywał kontrakt API.

Aby temu zaradzić, NestJS 12 zawiera StandardSchemaSerializerInterceptor, który sprawdza i przekształca dane wysyłane przed ich dotarciem do klienta.

Naprzимер:

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

Rezultatem jest pełna obsługa walidacji na obu etapach cyklu żądania:

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

Dla usług opartych głównie na API ta symetria stanowi istotną poprawę.

6. Wbudowana możliwość obserwacji za pomocą @nestjs/observe

NestJS 12 wprowadza również dedykowany pakiet do obserwacji:

@nestjs/observe

To, co go wyróżnia, to świadomość wewnętrznej struktury NestJS. Zwykły agent monitoringu widziałby jedynie coś w rodzaju:

POST /users
200

Narzędzia dostępne w NestJS mogą natomiast rozpoznawać konstrukcje wyższego poziomu, takie jak kontrolery, dostawcy, rozwiązujące zapytania GraphQL, konsumenty kolejek, zadania oraz mikrosługi.

To narzędzie obejmuje kilka obszarów, w tym HTTP, GraphQL, gRPC, mikrosługi, konsumenty kolejek oraz zadania cron.

Celem jest traktowanie możliwości obserwacji jako elementu wbudowanego w cykl życia aplikacji, a nie czegoś dodawanego z zewnątrz na poziomie serwera HTTP.

7. Możliwość obserwacji to kwestia, która powinna interesować zespół QA

Z perspektywy QA ten warstwa obserwacji zasługuje na uwagę.

Testowanie nie powinno się kończyć w momencie, gdy API wysyła odpowiedź:

200 OK

Warto zrozumieć, co dokładnie wydarzyło się podczas generowania tej odpowiedzi.

Rozważmy żądanie przepływające przez system w następujący sposób:

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

Jeśli wykonywanie żądania trwa trzy sekundy, sam status 200 nie opisuje całej sytuacji.

To, co naprawdę chcemy wiedzieć, to gdzie upłynęły te trzy sekundy.

Potencjalne przyczyny obejmują:

• wolne zapytania do bazy danych
• opóźnienia spowodowane zewnętrznym API
• czas spędzony na przetwarzaniu w logice aplikacji

zaległości w kolejce

niespodziewane próby ponownej realizacji

Dane dotyczące obserwowalności dostarczają zespołom QA i inżynieryjnym dodatkowego źródła informacji, które pomagają powiązać niepowodzenia testów z rzeczywistym zachowaniem w produkcji.

8. Walidacja konfiguracji przechodzi na standardowe schematy

Zarządzanie konfiguracją to kolejna dziedzina, która przechodzi aktualizacje.

W przeszłości wiele aplikacji NestJS polegało na bibliotece Joi do tego celu:

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

W NestJS 12 walidacja konfiguracji przekształca się na standardowe schematy zamiast tego.

Oto jak to wygląda w praktyce:

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

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

Biblioteka Joi nie została porzucona — istniejące projekty mogą nadal nią korzystać, ale będą musiały zaktualizować się do wersji Joi 18 lub nowszej oraz przenieść wszystkie ustawienia specyficzne dla biblioteki pod:

validationOptions.libraryOptions

To jest częścią szerszych działań zmierzających do stworzenia wspólnego interfejsu schematów w całym ekosystemie frameworka.

9. Konfliktujące trasy mogą być teraz wykrywane automatycznie

Istnieje subtelna pułapka w projekcie API, której często trudno jest dostrzec, dopóki nie spowoduje problemów.

Załóżmy, że zdefiniowaliśmy te dwa obsługiwacze:

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

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

W zależności od sposobu rozwiązywania tras oraz kolejności ich deklaracji, żądanie skierowane do:

/users/me

może ostatecznie pasować do wzorca:

/users/:id

Zamiast trafić do dedykowanego obsługiwacza /me, jak to zamierzono.

NestJS 12 dodaje funkcję diagnostyczną, której można używać według potrzeb, aby wykrywać tego typu niejednoznaczności tras.

Włączasz ją w ten sposób:

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

    routeResolutionStrategy:
      'specificity',
  },
);

To pozwala programistom proaktywnie wykrywać niejednoznaczne reguły routingu, zamiast natknąć się na nie później w mylącej odpowiedzi API.

10. Kody błędów, które maszyny mogą faktycznie rozszyfrować

Kolejna mała modyfikacja może okazać się bardzo ważna dla wszystkich, którzy korzystają z twojej API.

Weźmy ten przypadek wyjątku:

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

Rozwijający interfejs użytkownika może być skłonny do bezpośredniego porównywania z tekstem komunikatu:

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

Taki podejście jest kruche, ponieważ sformułowania mogą ulec zmianie.

Lepszym rozwiązaniem jest użycie stabilnego kodu błędu:

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

Klient może wtedy sprawdzić go według:

WEAK_PASSWORD

Zamiast polegać na dokładnym sformułowaniu komunikatu.

Jest to tym ważniejsze, gdy API jest używane przez kilku odbiorców, na przykład:

• interfejs użytkownika internetowego
• aplikację mobilną
• API przeznaczone dla partnerów
• służby wewnętrzne

Wszyscy oni mogą polegać na tym samym, spójnym identyfikatorze błędu zamiast analizować tekst czytelny dla ludzi.

Strukturalne logowanie otrzymuje ulepszenie

W tym wydaniu doszło również do ulepszeń w obszarze logowania.

Teraz możesz pisać coś w stylu:

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

Argument obiektu jest traktowany jako dane strukturalne dołączone do konkretnej linii logu, a nie tylko jako dodatkowy tekst do wydruku.

Gdy jest włączony tryb wyjścia JSON, te dane strukturalne pojawiają się pod kluczem params, lub można je bezpośrednio włączyć do wpisu logu za pomocą opcji flattenParams.

Jest to bardzo ważne, jeśli twoje logi trafiają do systemu monitoringu lub obserwowalności. Zamiast wysyłać zwykłe łańcuchy znaków, które muszą być później analizowane, twoja aplikacja może wysyłać wpisy strukturalne, które od samego początku można filtrować i wyszukiwać.

Naprzимер, wpis logu może wyglądać w ten sposób:

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

Taki format jest o wiele łatwiejszy do zapytania niż próba wydobywania pól z wiadomości w formacie tekstowym.

CLI przeszedł przebudowę

Kolejną istotną zmianą w tym wydaniu jest całkowita przebudowa interfejsu CLI.

Jego baza kodu przeniesiona została do formatu ESM. Zestaw testów zmieniono z Jest na Vitest. Dodano pełną obsługę testowania end-to-end dla poleceń CLI, a struktura wewnętrznych poleceń została przepracowana wokół obiektów kontekstowych typowanych.

Żadna z tych zmian nie musi bezpośrednio wpływać na kod twojego aplikacji. Jest to jednak sygnał, że działania modernizacyjne nie ograniczają się tylko do samego środowiska wykonawczego — narzędzia i procesy pracy programistów również są aktualizowane.

nest upgrade upraszcza ścieżkę migracji

Przebudowany interfejs CLI zawiera nowe polecenie:

nest upgrade

Zanim cokolwiek zastosujesz, możesz sprawdzić, co ma zostać zmienione:

Before running it, you can preview the changes:

Jest to istotne, ponieważ większe aktualizacje wersji często wpływają na wiele małych, niespowiązanych ze sobą detalów konfiguracji. Polecenie aktualizacji może automatycznie obsłużyć takie zmiany, jak:

• zmiana wersji pakietów @nestjs/*
• aktualizacja konfiguracji webpacka
• zamiana GraphQL Playground na GraphiQL
• dostosowanie sposobu transmisji danych w GraphQL
• aktualizacja pakietów związanych z NATS
• dostosowanie użycia @nestjs/config
• aktualizacja zależności Jest
• aktualizacja zależności Joi

Gdy proces zostanie zakończony, wyświetla się podsumowanie tego, co zostało zmienione automatycznie, a co nadal wymaga ręcznej weryfikacji.

Nowo utworzone projekty rozpoczynają się od nowoczesnych standardów

Budowa zupełnie nowego projektu przy użyciu NestJS 12 zapewnia teraz inny punkt wyjścia.

Nowe konfiguracje monorepo domyślnie używają Rspack jako narzędzia do pakowania. Nowe projekty wykorzystują oxlint zamiast ESLint. Vitest jest teraz domyślnym narzędziem do wykonywania testów w projektach opartych na ESM. Bun jest również akceptowany jako opcja menedżera pakietów, obok istniejących rozwiązań:

npm
yarn
pnpm

To wszystko nie zmienia retroaktywnie istniejących projektów — ta różnica jest ważna. NestJS 12 po prostu ustanawia nowocześniejszą podstawę dla wszystkiego, co zostanie stworzone w przyszłości, pozwalając jednocześnie aplikacjom już istniejącym na migrację we własnym tempie.

Konfiguracje GraphQL wymagają szczególnej uwagi

Jeśli uruchamiasz aplikację GraphQL, istnieją prace migracyjne, których nie powinieneś pominąć.

GraphiQL zastępuje teraz GraphQL Playground jako domyślne środowisko programistyczne. Co ważniejsze, obsługa:

subscriptions-transport-ws

została całkowicie usunięta. Oczekuje się od Ciebie przeniesienia się na:

graphql-ws

Te dwa protokoły nie są ze sobą kompatybilne na poziomie transmisji danych. Oznacza to, że zmiana sposobu przesyłania subskrypcji w backendzie to nie tylko zmiana dotycząca samego backendu — wszystko, co korzysta z tych subskrypcji, również musi zostać zaktualizowane i przetestowane:

NestJS API
↓
GraphQL Subscription
↓
Web / Mobile Client

Samodzielna aktualizacja zależności po stronie serwera nie wystarczy, aby wszystko działało poprawnie od początku do końca.

Wsparcie dla NATS również uległo zmianie

Framework zastępuje teraz pakiet nats następującym:

@nats-io/transport-node

Jeśli twoja aplikacja importuje stary pakiet bezpośrednio, będziesz musiał zaktualizować zarówno samą zależność, jak i odpowiadające im instrukcje importu.

Zmienił się również sposób obsługi pakietów: dane treściowe są teraz serializowane jako łańcuchy JSON, a każdy własny deserializator, który napisałeś, otrzyma pełny obiekt wiadomości NATS zamiast już przetworzonych danych treściowych. Możesz odczytać zawartość danych treściowych za pomocą:

msg.json()

Jeśli komunikacja jest kluczową częścią twojego systemu, to jest obszar, który warto wyraźnie wskazać w planach testów integracyjnych i regresyjnych.

17. Zmieniła się kolejność hooków cyklu życia

Istnieje jeszcze jedna zmiana mogąca wpłynąć na funkcjonowanie związaną z hookami cyklu życia.

W NestJS 12 kolejność uruchamiania hooków cyklu życia zależy teraz od pozycji komponentu w hierarchii.

To ma znaczenie, jeśli twoja aplikacja polega na określonej sekwencji podczas:

• inicjalizacji
• uruchamiania
• zamykania
• rozwiązywania

Załóżmy, że usługa uruchamia zasoby w następującej kolejności:

Database
Queue
Cache
External API

A inna usługa zakłada, że jeden z tych zasobów jest już dostępny. Po aktualizacji warto sprawdzić, czy to założenie nadal jest prawdziwe.

To właśnie ten typ zmiany, która niekoniecznie objawia się jako błąd kompilacji. Twój projekt może skompilować się bez błędów, a mimo to działać inaczej w czasie wykonywania.

18. Dodatkowe zmiany, o których warto wiedzieć

Część tej wersji obejmuje jeszcze kilka innych modyfikacji.

NestJS 12 dotyczy również:

• formy odpowiedzi na błędy walidacji
• sposobu obsługi wyjątków gRPC
• porównywania wzorów regularnych w Kafka
• bramek WebSocket o zasięgu żądania
• przyczyn zgłaszanych przy rozłączeniu się z WebSocket
• hooki przed żądaniem dla mikrousług
• bezpiecznego zamykania w Express
• sposobu mapowania błędów przez adapter HTTP

Większość projektów nie będzie korzystać ze wszystkich tych funkcji. Jednak tam, gdzie aplikacja faktycznie polega na jednej z tych możliwości, warto dodać specjalistyczne testy regresji dla niej.

19. Na czym powinien skupić się QA po aktualizacji?

To jest chyba najważniejsze pytanie, na które trzeba odpowiedzieć.

Potwierdzenie, że aktualizacja głównego frameworka przebiegła pomyślnie, nie powinno opierać się wyłącznie na uruchomieniu:

npm test

Zamiast tego testy powinny być podzielone na odrębne obszary.

API

• autoryzację
• upoważnienia
• weryfikację
• odpowiedzi na błędy
• pasowanie tras
• serializację odpowiedzi

Konfiguracja

Sprawdź:

• konieczne zmienne środowiskowe
• nieważne wartości
• wartości domyślne
• konfigurację produkcyjną
• konfigurację testową

GraphQL

Gdzie to ma znaczenie:

• Zapytania
• Mutacje
• Subskrypcje
• GraphiQL
• Kompatybilność klienta

Mikrosługi

Gdzie to ma znaczenie:

• NATS
• Kafka
• gRPC
• Serializacja wiadomości
• Ponawianie prób
• Rozwiązywanie wyjątków

Obserwowalność

Jeśli jest włączone:

• Ślady HTTP
• Ślady GraphQL
• Zadania w tle
• Konsumenty kolejek
• Błędy
• Zadania cron

Zamknięcie

Należy sprawdzić:

• Rozwiązywanie sygnału SIGTERM
• Aktywne żądania
• Połączenia z bazą danych
• Kolejki
• Pracownicy w tle

Celem nie jest odpowiedź na:

">Czy aplikacja uruchamia się?"

Celem jest odpowiedź na:

">Czy aplikacja nadal zachowuje się prawidłowo we wszystkich istotnych sytuacjach?"

20. Co oznacza ta wersja dla pracy z testami jakości

Warto zwrócić uwagę na szerszy trend.

Frameworki stają się coraz bardziej zautomatyzowane. Walidacja jest standaryzowana, a możliwości obserwacji są wbudowywane bezpośrednio. Logi są domyślnie strukturyzowane, a konflikty tras mogą być wykrywane automatycznie. Narzędzia do testowania stają się coraz szybsze.

Żadne z tych zmian nie eliminuje potrzeby testów jakości. One jedynie zmieniają obszary, w których testy jakości przynoszą największą wartość.

Zamiast pytać tylko:

">Czy ten endpoint działa?"

Testy jakości powinny coraz częściej pytać:

">Czy umowa API jest nadal poprawna?" ">Czy błędy są widoczne?" ">Czy uprawnienia są prawidłowo egzekwowane?" ">Czy błędy są czytelne dla maszyn?" ">Czy serializacja jest poprawna?" ">Czy aplikacja odzyskuje stan w odpowiedni sposób?" ">Czy ta aktualizacja zmienia istniejące zachowanie?"

Framework może samodzielnie automatyzować niektóre sprawdzenia. Jednak osoba musi nadal zdecydować, co w ogóle wymaga sprawdzenia.

21. Zalecana ścieżka migracji do NestJS 12

Zamiast bezpośrednio aktualizować środowisko produkcyjne, najpierw sprawdź swoje środowisko:

node --version

Potwierdź, że używasz:

Node 20.19+

lub:

Node 22.12+

Następnie zaktualizuj CLI:

npm i -g @nestjs/cli@latest

Zobacz wstępny przegląd tego, co zrobi migracja:

nest upgrade --dry-run

Przeanalizuj uważnie wyniki. Następnie zastosuj je:

nest upgrade

Po tym uruchom:

npm test

wraz ze swoimi testami integracyjnymi i end-to-end.

Zwróć szczególną uwagę na wszelkie funkcjonalności oparte na:

• GraphQL
• NATS
• weryfikacji konfiguracji
• spersonalizowanych przetwornikach
• hakach cyklu życia
• Webpack
• narzędziach opartych na CommonJS

Każda z tych dziedzin wymaga osobnej analizy pod kątem aspektów migracyjnych.

Ostateczne uwagi

NestJS 12 to nie tylko dodanie kolejnej funkcji.

Jest to krok w kierunku dostosowania NestJS do obecnego rozwoju ekosystemu Node.js i TypeScript.

ESM jest teraz integralną częścią samej architektury pakietów.

Standard Schema otwiera framework na użycie bibliotek weryfikacji takich jak Zod, Valibot, ArkType i inne.

To samo ekosystem schematów może być również wykorzystywany do serializacji.

Obserwowalność jest teraz ściślej powiązana z własną strukturą aplikacji Nest.

Interfejs wiersza poleceń został przeprojektowany wokół nowocześniejszych narzędzi.

Rspack, Vitest, oxlint i Bun stają się elementami nowoczesnego setupu NestJS.

Jednocześnie nic z tego nie zmusza istniejących aplikacji do natychmiastowej zmiany wszystkiego.

Możesz swobodnie pozostać przy CommonJS.

Możesz nadal korzystać z walidacji opartej na klasach.

Przejście na Vitest lub oxlint nie jest natychmiast obowiązkowe.

Ta elastyczność jest chyba najpraktyczniejszym aspektem tej wersji.

NestJS 12 aktualizuje framework, nie wymagając od każdej istniejącej aplikacji natychmiastowej modernizacji.

Dla programistów oznacza to większą swobodę w doborze własnego tempa.

Dla inżynierów QA oznacza to kolejne ważne aktualizacje frameworka, które trzeba zweryfikować — nie tylko na poziomie kodu, ale także w zakresie API, integracji, możliwości obserwowania działania aplikacji, konfiguracji oraz rzeczywistego zachowania w środowisku produkcyjnym.

Dokładnie tutaj aktualizacje frameworka stają się interesujące.

Zmiana numeru wersji w pliku package.json to część prosta.

Najważniejsze jest to, czy aplikacja nadal funkcjonuje tak, jak oczekują ci, którzy na niej polegają.

Literatura pokrewna

• Dzielenie się jednym schematem Zod pomiędzy frontendem React a backendem Node — Dowiedz się, jak jeden schemat Zod może weryfikować formularze React, odpowiedzi API, treści zapytań Express oraz zmienne środowiskowe, jednocześnie generując odpowiadające im typy TypeScript.

Kompilator TypeScript do Go i wykonywanie natywne: przewodnik migracji — Dowiedz się, jak kompilator TypeScript oparty na Go oraz wykonywanie natywne w Node.js wpłyną na projekty React i Next.js oraz co należy natychmiast poprawić w pliku tsconfig.