Files

T

julien 96da68e18e chore(deps): upgrade to Express 5 and remove redundant middleware

- Express 4 → 5.2.1
- Remove method-override (unused with Angular HttpClient) and errorhandler (superseded by exceptions.handler.js)
- Remove asyncHandler wrapper from all controllers — Express 5 propagates async rejections natively
- Remove body-parser (redundant, Express 5 includes it internally)
- Patch/minor updates: cors, dotenv, ejs, express-jwt, express-session, jsonwebtoken, morgan, mysql2, sequelize, underscore
- Dev updates: eslint 9.0→9.39, nodemon 2→3, globals, sequelize-cli
- Fix getUser endpoint to include SkydiverProfile data in response
- docs: add ADR 0013, update README

2026-05-01 20:42:39 +02:00

3.2 KiB

Raw Blame History

Upgrade Express from v4 to v5 and remove redundant middleware

Status: accepted
Date: 2026-04-28

Context and Problem Statement

The API ran on Express 4.18, with two additional middleware packages (method-override, errorhandler) and an asyncHandler wrapper used across all controllers to forward async errors to Express. Express 5 was released as stable in September 2024 and addresses the async error handling gap natively.

Decision Drivers

Express 5 propagates promise rejections in route handlers to error middleware automatically — the asyncHandler wrapper is redundant noise.
method-override allows clients to tunnel PUT/DELETE via POST using a _method parameter. The API is consumed exclusively by Angular's HttpClient, which sends correct HTTP verbs directly. The middleware has never been exercised.
errorhandler provides verbose error pages in development, but a custom exceptions.handler.js already handles error formatting for all environments.
Removing unused middleware reduces the attack surface and the number of dependencies to keep up to date.

Considered Options

Stay on Express 4, keep existing middleware
Upgrade to Express 5, keep method-override and errorhandler for safety
Upgrade to Express 5 and remove all three redundant pieces

Decision Outcome

Chosen option: "upgrade to Express 5 and remove all three redundant pieces", because the migration has zero breaking changes for this codebase (no wildcard routes, no removed APIs in use) and each removed package was demonstrably unused or superseded.

Changes made:

express bumped to ^5 (installed 5.2.1)
method-override removed from package.json and createApp.js
errorhandler removed from package.json and createApp.js
asyncHandler wrapper removed from all 8 controllers and its middleware file deleted
Controller exports changed from asyncHandler(async (req, res, next) => { ... }) to async (req, res, next) => { ... }

Positive Consequences

Unhandled async errors now reach the error handler without any wrapper — less boilerplate in every controller.
Two dependencies removed from the production bundle (method-override, errorhandler).
Codebase is on a maintained major version with long-term support.

Negative Consequences

Express 5 is a major version bump — future middleware additions must be verified for Express 5 compatibility before adoption.

Pros and Cons of the Options

Stay on Express 4

Good, because no migration effort.
Bad, because the async error gap requires the asyncHandler wrapper indefinitely.
Bad, because method-override and errorhandler remain as unused surface area.

Upgrade to Express 5, keep existing middleware

Good, because conservative — no behavioural changes beyond async propagation.
Bad, because method-override and errorhandler are still dead weight.

Upgrade to Express 5 and remove all three

Good, because every removed package is one fewer dependency to audit and update.
Good, because controller code is simpler without the wrapper.
Bad, because a future Express 4-only middleware would need to be replaced — acceptable trade-off given the ecosystem has largely moved to v5.

3.2 KiB Raw Blame History