TypeError: Missing parameter name at 2: https://git.new/pathToRegexpError

[eru123]

Environment information

Version: v5.1.0

Platform: Linux 6.8.0-1021-aws 23~22.04.1-Ubuntu SMP Tue Dec 10 16:50:46 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Node.js version: v16.20.2

Any other relevant information: N/A

What steps will reproduce the bug?

# Installing the latest express cause the issue
npm install express

then throws error

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

Temporary Fix

Downgrade to 4.21.2

npm install express@4.21.2

[MrShadow50]

yes I got also same issue

[slagiewka]

I you go to the DEBUG_URL: https://git.new/pathToRegexpError

You will see in the README:

Missing parameter name
Parameter names must be provided after : or *, and they must be a valid JavaScript identifier. If you want an parameter name that isn't a JavaScript identifier, such as starting with a number, you can wrap the name in quotes like :"my-name".

I would assume that your route contains *. Please confer the migration guide before opening issues: https://expressjs.com/en/guide/migrating-5.html#path-syntax

PS: Node.js version: v16.20.2 please note that express v5 requires node v18. Also note that node v16 has ben EoL since September 11th, 2023.

[wesleytodd]

Yep, as @slagiewka says, please read our migration guide. v5 is a breaking upgrade, and you will need to make some changes to the path syntax you use. If you still think this is a bug after addressing the changes from the guide, please post the route definitions you have and we can take a look. I will leave this open only because I anticipate more folks asking the same question, but will remove the bug label as this is likely not a bug.

[NetWin]

I had this problem aswell and can confirm that this is "simply" a breaking change from the V5 update.
As described in the changelogs here routes like app.use('/**', ...) are not supported anymore.

This problem came up while updating express in an Angular SSR application for me. When setting up SSR, Angular generated exactly the example mentioned above for me. But changing it to app.use('/{*path}', ...) fixed the problem for me. 👍

Screenshot from the migration section of the express homepage:

[eru123]

Thanks @wesleytodd and @slagiewka, I confirmed that it is a breaking issue with the new version.

As for our usecase we only have this one route, that accepts all requests and send in the index.html of our frontend build, and you guys are correct, this one is causing the issue.

app.get('/*', function (req, res) {
  res.sendFile(path.join(__dirname, '../build', 'index.html'));
});

I opened this issue yesterday because we have to rollback our production and it cost us downtime and delay our app release thinking it's a fault on our recent changes.

Funny enough, it's our mistake, we have this untouched code in our Dockerfile for ~5 years now and a package-lock.json is not generated until deployment as we do the expressjs installation on docker build, basically it's always installing the latest version 😭.

RUN npm install express

With this, I conclude that this issue is resolved, you guys can close this anytime if no one wants to add more. I just hope no major impact to production servers out there because of silly mistakes like what we did.

[MrShadow50]

@eru123 same with me I am using express to serve my react build and last 3-year code was working but because I also face same issue after this critical issue, I realize does not matter how much contributor are working on any lib it can have major issue after whole application.

[wesleytodd]

This is true of all libraries, you have benefited these past years from the stability (and stagnation 😉) of the project. If you are doing something like npm install express in your build you need to specify a version you rely on. Change that to npm install express@5 now and then when we release v6 which will also include breaking changes you will avoid this pain.

I will still keep this open for now, because it avoids more duplicate issues, but glad to hear your issue is resolved @eru123!

[wesleytodd]

In fact, I just pinned this issue so that folks are more likely to see it than to open a new one.

[ManfredLange]

One case that creates this issue in my case is configuring CORS for pre-flight requests. In my case in express 4 the following worked:

this._app.options('*', corsSettings);

The first parameter here is a wild card which is no longer supported as such (without a name) in express 5.

For express 5 the following code works for me:

this._app.options(/.*/, corsSettings);

Note that in both cases the property this._app is defined as:

private readonly _app: express.Express = express();

Maybe this is of some value for others when upgrading to express version 5. Happy coding!

[noor-tg]

Hi,

I have 2 routes like this

// error in this route
ApiRequestsRouter.get("/:request_id(\\d+)", ApiRequestsController.show);
ApiRequestsRouter.use([isAuth, isBand]);
ApiRequestsRouter.get("/mines", ApiRequestsController.mine);

In v4 this works. in v5 I see error about pathtoRegexpError Like the title

I can't use

// this route is protected by auth
ApiRequestsRouter.get("/mines", ApiRequestsController.mine);
// this is without auth
ApiRequestsRouter.get("/:request_id", ApiRequestsController.show);

so how to fix this for express v5.1 ?

[bjohansebas]

I don't quite understand your problem, but from what I gather, you're having issues with /:request_id(\\d+). The solution would be to change it to /:request_id (as you already mentioned) and then check if :request_id is a number inside ApiRequestsController.show.

Is that the solution for now? Maybe @blakeembrey can confirm it.

[noor-tg]

I don't quite understand your problem, but from what I gather, you're having issues with /:request_id(\\d+). The solution would be to change it to /:request_id (as you already mentioned) and then check if :request_id is a number inside ApiRequestsController.show.

Is that the solution for now? Maybe @blakeembrey can confirm it.

the problem is I have routes in same level. which handle other things. like /reqests/:request_id should only check /reqests/123 but not /requests/disagree

the only solution I found on route level is to add prefix to the id route. which is breaking change.

[thetumper]

Not to poke the dead bear, but why were the path changes made? I guess many (at least myself), found the '*' more meaningful and understandable what it applied to, vs. '/{*something}'. I'm sure there was a reason, but is it helping the most people?

[wesleytodd]

@thetumper this might help: https://blakeembrey.com/posts/2024-09-web-redos/

I think it is linked and called out in both the changelogs and original release announcement. Let us know if there are other places you looked but didn't see it so we can update those with description and links.

[TimoPot]

When using Angular SSR and server.get('.',.... to do something with static files, make sure to change '.' into /.[a-zA-Z0-9]+$/

[Samuelplim]

In my case I had a route like in the example '/:file.:ext?' using @expressjs/codemod it was not possible to detect where it was, I was testing starting the server with small groups of files

[bjohansebas]

@Samuelplim @expressjs/codemod doesn't modify routes, I don't understand what you mean.

[detobel36]

For people who use Angular, the upgrade has been done here: angular/angular-cli#29989

[rajneeshshukla1608]

Go back to previous version this will fix the error

[Kaike-R]

Hey everyone,

I had the same issue, and I worked around it using a regex:
app.get(/.*/, (req, res) => { res.sendFile(path.resolve(__dirname, "frontend", "index.html")); });

Not sure if this will solve your problem too, but it worked for me!

[denniac]

I had the same issue upgrading to Express 5 with Angular 20 and node lts/jod (v22.16.0); I had to roll back to express@4.21.2.

[bjohansebas]

hey @Kaike-R @Deni8dev Changing the route to /{*splat}, doesn't it work?

[Kaike-R]

@bjohansebas I tested it here, and it worked for me too! I haven’t gone deep into the discussion, but I noticed there are three workarounds for this problem. Among these—{/{splat}},{ /./}, and {'/*\w'} —which one is the most recommended?

[tagobuyhelp]

I have been trying to fix this problem for three to four hours and after seeing this post, I got the temporary fix and got the job done for now.

[RijanDhakal]

Hey everyone,

I had the same issue, and I worked around it using a regex: app.get(/.*/, (req, res) => { res.sendFile(path.resolve(__dirname, "frontend", "index.html")); });

Not sure if this will solve your problem too, but it worked for me!

man thats freaking helpful , i was seacrhing for this from hours i added '/.*/' it added undeined like my fetchURl + undeined + route , so i just set the fecthing of data without fetch url. I was stuck to this for hours man

[ikwijaya]

still issue for me today
express 5.1.0

the error in console

[RijanDhakal]

const _dirname = path.resolve(); app.use(express.static(path.join(_dirname , "frontend/dist"))) app.get('/*w', async(req , res) => { res.sendFile(path.resolve(_dirname , "frontend" , "dist" , "index.html")); })

…

Message ID: ***@***.***>

[bjohansebas]

Please check the migration guide, it shows how routes should be set up. We know that not all functionalities are available yet, due to direct regex support, but it is in the process of being added (see pillarjs/path-to-regexp#379, pillarjs/path-to-regexp#380). Please only report when a route no longer works because the change was not documented.

[gh-andre]

I ran into the same problem when migrating to Express v5 and it seems to me that the reason this problem is reported so much isn't because people don't read the docs, but rather because the docs on this topic are somewhat rudimentary. I don't mean to say this in a negative way - just describing how reading all the docs I could find wasn't quite enough for me to figure it out, and it took some wading through the code and experimentation to get my paths working.

e.g. The v5 docs just show simple examples with fun names like *splat and :slug rather than focusing on realistic paths. The link from v5 docs leads to the page named route "parameters", which is shared between v4 and v5, with a generic caution that regex patterns are no longer being accepted in v5, and a link to the migration guide, which takes me back to *splat and :slug.

It took me some time to learn that there is no more unified way to define a path with parameter validation, which in v4 would look like this.

"/:page_id([0-9]+)*/:name([a-z0-9 +._-]+\\.[a-z0-9]+)"

Instead, there are now two distinct primary ways to define paths - path-to-regexp syntax, which has no built-in parameter validation, or plain regex syntax, which is more complex and potentially error-prone than path patterns. It also took me more time to figure out whether regex paths even provide named parameters, but then I found a Stack Overflow thread that described how to do that, and later the comment #6723 (comment) from @eru123 in this thread describing the same. So, now I can keep my validation rules and parameter names in v5 like this:

/\/(?<page_id>[0-9]+)(?:\/[a-z0-9]+)*\/(?<name>[a-z0-9 +._-]+\.[a-z0-9]+)/

Using named capture groups puts page_id and name into req.params, which makes it similar to regex patterns in v4, even though not not as versatile as per-parameter regex in v4.

Perhaps people would be less likely to run into these errors if the v5 docs described more of common everyday paths with regex and path patterns. Maybe it's also worth mentioning that path-to-regexp must be accompanied by extra validation via packages like joi, etc., to avoid security risks, and also to provide better error handling in that bad paths will trigger validation errors instead of route-not-found errors, like with regex paths above.

Lastly, just for the fun of it, I never saw GPT-5, Claude and Gemini fail as spectacularly as they all did with this topic - any way I tried to phrase questions about route paths in v5, I consistently got back misleading advice and broken examples from all of them.

[GabrielBB]

Biggest downgrade in programming history