API with NestJS #186. What’s new in Express 5?

February 10, 2025

This entry is part 186 of 186 in the API with NestJS

With NestJS 11, the framework now comes with Express 5 by default. While the update is mostly painless, there are some breaking changes to consider. In this article, we go through what new features Express 5 brings to the table and how it affects NestJS.

Installing Express 5

Express 4 was released in April 2014. After many years of development, Express 5 was officially released in 2024. Since then, it has become a stable version, but it’s not installed by default.

1	npm install express

When we run the above command, we install Express 4. To install Express 5, we need to use the next tag.

1	npm install express@next

Handling rejected promises

When handling requests with Express, we usually have to do some asynchronous operation. A good example is fetching an article with a given ID from our database.

import express from 'express';

import { getArticleWithId } from './getArticleWithId';

const app = express();

app.get('/articles/:id', async function (request, response) {

const id = request.params.id;

const article = await getArticleWithId(id);

response.send(article);

});

app.listen(3000, () => {

console.log('Listening on the port 3000');

});

Express 4

In Express 4, if the getArticleWithId returns a promise that is rejected, our entire Express application crashes. To deal with that, when using async/await, we have to use the try...catch block in every router handler.

Alternatively, we can use libraries such as express-async-errors.

import express from 'express';

import { getArticleWithId } from './getArticleWithId';

import { NotFoundException } from './NotFoundException';

const app = express();

app.get('/articles/:id', async function (request, response) {

const id = request.params.id;

try {

const article = await getArticleWithId(id);

response.send(article);

} catch (error) {

if (error instanceof NotFoundException) {

response.sendStatus(404);

} else {

response.sendStatus(500);

}

});

Feel free to handle more types of errors.

Express 5

With Express 5, having an unhandled promise rejection does not crash the application. Instead, our API responds with the 500 Internal Server Error. We can use that to implement elegant error handling.

import express, { ErrorRequestHandler } from 'express';

import { getArticleWithId } from './getArticleWithId';

import { NotFoundException } from './NotFoundException';

const app = express();

app.get('/articles/:id', async function (request, response) {

const id = request.params.id;

const article = await getArticleWithId(id);

response.send(article);

});

const errorHandler: ErrorRequestHandler = (error, request, response, next) => {

if (error instanceof NotFoundException) {

response.sendStatus(404);

} else {

response.sendStatus(500);

}

};

app.use(errorHandler);

It’s crucial to list four arguments in our error middleware, even if we don’t use all of them. This is how Express recognizes that it’s an error middleware.

With our above approach, if the getArticleWithId function returns a promise that is rejected, Express 5 runs our error handler instead of crashing the application.

NestJS

It’s important to note that this change in Expres 5 does not affect our NestJS projects. NestJS has a built-in exception layer that handles all unhandled exceptions throughout the application, regardless of whether it’s using the latest version of Express or not.

Revised path route matching

When we implement our API, we are usually strict when defining our routes. For example, this handler runs only when the user requests the /articles endpoint.

app.get('/articles', async function (request, response) {

// ...

});

However, we can also define a handler that matches multiple different routes.

Express 4

To do that with Express 4, we simply use the * wildcard.

app.get('/articles*', async function (request, response) {

response.send({

message: 'Hello World!',

});

With the above code, we respond with Hello World for every request in our application that starts with /articles.

Express 5

With Express 5, we need to name our wildcard.

app.get('/articles/*allRoutes', async function (request, response) {

response.send({

message: 'Hello World!',

});

Thanks to the above code, we also respond with Hello World. However, it does not match the root path, which is /articles. If we want to include it, we need to wrap the wildcard with braces.

app.get('/articles/{*allRoutes}', async function (request, response) {

response.send({

message: 'Hello World!',

});

However, the above solution requires the user to request /articles/ with the / at the end. With Express 4, we could have used the ? sign to mark an optional character, but this does not work with Express 5 anymore. We have to use braces instead.

app.get('/articles{/*allRoutes}', async function (request, response) {

response.send({

message: 'Hello World!',

});

Since the last / character is inside the braces, it’s optional.

NestJS

The above might affect your NestJS project if you’re using advanced pattern matching using wildcards, optional characters, or regular expressions. The strings we pass to the decorators, such as @Get() and @Post(), directly correspond with the routes set up by Express.

@Get('articles{/*allRoutes}')

findAll() {

return {

message: 'Hello world!'

}

Parsing query parameters

We can send query parameters when making requests to our API.

1	/articles?authorId=9

Express 4

Besides simple cases, Express 4 can handle query parameters with nested object parameters and arrays.

1	GET /articles?where[authorId]=1&tags[]=nodejs&tags[]=typescript

interface ArticlesParams {

where?: {

authorId: string;

tags?: string[]

}

app.get('/articles', async function (request, response) {

const queryParams: ArticlesParams = request.query;

const tags = queryParams.tags || [];

const articles = await getArticles(tags, queryParams.where?.authorId);

response.send(articles);

});

Expres 5

Express 5 no longer uses the qs library to parse query parameters by default. This means that it can’t handle advanced cases such as the one above by default. We can change the query parser back to the old one if we need it.

const app = express();

app.set('query parser', 'extended');

NestJS

The same applies to our NestJS applications. We need to change the query parser if we need advanced query parameters handling.

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

import { NestExpressApplication } from '@nestjs/platform-express';

import { AppModule } from './app.module';

async function bootstrap() {

const app = await NestFactory.create<NestExpressApplication>(AppModule);

app.set('query parser', 'extended');

await app.listen(3000);

}

bootstrap();

Removed methods and properties

Express 5 deprecates and removes a bunch of methods and properties that are no longer supported. Most of the changes are intended to clean up the code and simplify the API. For a full list of deprecated functions, check out the official documentation.

None of the above changes should affect our NestJS applications.

Summary

The release of Express 5 marks a milestone, showcasing ten years of development by the Express team. Because it’s such a long time, it’s difficult to list all of the changes. In this article, we’ve gone through the most important ones and those that can affect our NestJS projects. If you want to learn more, check out the checklist in the release pull request and the official migration guide from the Express team.

While Express 5 still does not install by default, NestJS 11 now uses it out of the box. We can already see that it increased the number of weekly downloads of Express 5. Hopefully, this will soon convince the Express team that the latest version should be installed by default.

Series Navigation<< API with NestJS #185. Operations with PostGIS Polygons in PostgreSQL and Drizzle