Maru@maru

Dev Hub

Translated from Korean

NestJS 11 Release: Key Changes and Practical Upgrade Guide

NestJS, a widely used backend framework in the Node.js ecosystem, has reached version 11. This major update focuses on aligning the framework's internal engine with modern HTTP libraries and reducing the boilerplate code that often complicates containerized production environments.

The first thing to check is the minimum runtime requirements. Starting with NestJS 11, support for Node.js 16 and 18 has been completely dropped, now requiring Node.js 20 or higher. If you are not already using a runtime that meets the current LTS version or higher, you should verify your environment first.

Adoption of Express 5 and Changes to Route Wildcard Rules

The default HTTP platform adapter has been switched to Express 5, and official support for Fastify 5 has also been introduced. The area most significantly impacted by this change is how wildcard route paths are declared.

In Express 5, the path matching algorithm has been improved, and the use of unnamed standalone asterisk (*) wildcards is no longer permitted. Any existing wildcard paths used to intercept all routes must now be updated to a named format.

The @Get('users/\*') format used to handle sub-paths in controllers must be updated to a named parameter format such as @Get('users/\*splat'). Similarly, commonly used middleware configurations like forRoutes('\*') must be updated to an explicit wildcard syntax like forRoutes('\{\*splat\}') for the server to function correctly. If you upgrade dependencies without checking existing code, you may encounter route matching errors at startup.

Built-in JSON Structured Logging for ConsoleLogger

One of the most tedious tasks when deploying servers to Docker containers or Kubernetes environments was setting up JSON log output. In previous versions, developers often had to wrap external logging libraries or implement complex custom loggers to integrate with log aggregators like Datadog or CloudWatch.

NestJS 11 adds a native JSON output option to the default ConsoleLogger. You can now generate serialized logs with a single option without adding complex external dependencies.

As of NestJS 11, the main.ts bootstrap code is written as follows.

typescript

Once the option is enabled, timestamps, log levels, context, and messages are recorded to standard output in a standard JSON format. Nested objects, arrays, Maps, and Set structures are also formatted much more cleanly, making integration with log analysis pipelines significantly easier.

Improved Dynamic Module Loading Structure for Faster Boot Times

The boot delays that occurred when declaring many dynamic modules in large-scale projects have also been resolved. In previous versions, the framework serialized the entire metadata of a dynamic module into a string and generated a hash to identify the module's uniqueness. This approach increased CPU computational costs and memory consumption as the number of dynamic modules injecting large configuration objects or file data grew.

NestJS 11 has simplified the module identification logic by comparing object references directly instead of hashing metadata. As a result, the speed of cold starts and test context initialization has been significantly improved for applications that assemble many modules, such as microservices or monorepo structures.

Should you upgrade now?

If you are running services in a containerized environment with Node.js 20 or higher and want standardized JSON output without relying on external logger libraries, this upgrade is well worth it. If you haven't used excessive wildcards in your route paths, the migration process is also relatively straightforward.

However, if your project relies heavily on Express 4's query string parsing behavior or has complex legacy routing rules, you should first strengthen your test suite. I especially recommend conducting a full survey of wildcard routes and middleware matching paths before upgrading your dependencies step-by-step.

Loading comments…