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
This commit is contained in:
2026-05-01 20:42:39 +02:00
parent 59401b3c85
commit 96da68e18e
14 changed files with 1114 additions and 814 deletions
+61
View File
@@ -0,0 +1,61 @@
# 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.