The RegEx problem I faced when upgrading Express.js, v4.x to v5.x

Introduction

I ran into this while upgrading an Express.js app from version 4.x to 5.x. The application looked fine at first, but deployment started failing because one of my route patterns no longer worked with the newer router behavior.

The fix was small, but the error message was not immediately obvious. This post is a short note on what broke, why it happened, and the route pattern I changed.

The Error

After the upgrade, the app failed with this error:

TypeError: Missing parameter name at 1: https://git.new/pathToRegexpError
    at name (/var/task/node_modules/path-to-regexp/dist/index.js:73:19)
    at lexer (/var/task/node_modules/path-to-regexp/dist/index.js:91:27)
    at lexer.next (<anonymous>)
    at Iter.peek (/var/task/node_modules/path-to-regexp/dist/index.js:106:38)
    at Iter.tryConsume (/var/task/node_modules/path-to-regexp/dist/index.js:112:28)
    at Iter.text (/var/task/node_modules/path-to-regexp/dist/index.js:128:30)
    at consume (/var/task/node_modules/path-to-regexp/dist/index.js:152:29)
    at parse (/var/task/node_modules/path-to-regexp/dist/index.js:183:20)
    at /var/task/node_modules/path-to-regexp/dist/index.js:294:74
    at Array.map (<anonymous>)

The important part is Missing parameter name. Express 5 uses a newer path-to-regexp behavior, and some route patterns that were accepted in Express 4 are no longer valid.

What Changed

In Express 4, this kind of catch-all route was common:

app.get('/*', (req, res) => {
  // Handler code
});

In Express 5, the bare wildcard is no longer accepted in the same way. The wildcard must be named, because the path parser expects parameters to have names.

That means /* needs to become a named wildcard route.

The Fix

I changed the catch-all route to this:

app.get('{*splate}', (req, res) => {
  // Handler code
});

After that change, the route parser stopped throwing the error and the application started correctly again.

If you are using Express 5 and you see this error, search for routes that use *, /*, or other unnamed wildcard patterns. Those are good first suspects.

What I Learned

Major dependency upgrades can break code that has been quietly working for years. In this case, the application logic was not the problem. The route pattern itself had become invalid.

The safer upgrade flow is:

Read the migration notes before changing the version.
Start the app locally before deploying.
Check wildcard and regex-like route definitions carefully.
Keep the fix small and verify the exact route that failed.

This issue is easy to miss because the broken pattern often lives in fallback or catch-all routing code, not in the main route handlers you use every day.