http-errors
http-errors copied to clipboard
jshttp
populateConstructorExports calls toIdentifier with unknown
After updating NPM packages, this exception started happening on each request.
TypeError: Cannot read properties of undefined (reading 'split')
at toIdentifier (D:\home\site\wwwroot\node_modules\send\node_modules\toidentifier\index.js:24:6)
at forEachCode (D:\home\site\wwwroot\node_modules\send\node_modules\http-errors\index.js:245:16)
at Array.forEach (<anonymous>)
at populateConstructorExports (D:\home\site\wwwroot\node_modules\send\node_modules\http-errors\index.js:243:9)
at Object.<anonymous> (D:\home\site\wwwroot\node_modules\send\node_modules\http-errors\index.js:30:1)
at Module._compile (node:internal/modules/cjs/loader:1101:14)
at Object.Module._extensions..js (node:internal/modules/cjs/loader:1153:10)
at Module.load (node:internal/modules/cjs/loader:981:32)
at Function.Module._load (node:internal/modules/cjs/loader:822:12)
at Module.require (node:internal/modules/cjs/loader:1005:19)
Hi @michaellperry very strange. My first thought is that maybe there is a conflict somewhere with package versions, since you said it just happened after update? Can you paste the output of npm ls in your project?
Sure thing. Here's the npm ls before my workaround:
[email protected] /Users/michaelperry/Projects/ImprovingUCourseLibrary
├── @material-ui/[email protected]
├── @material-ui/[email protected]
├── @material-ui/[email protected]
├── @testing-library/[email protected]
├── @types/[email protected]
├── @types/[email protected]
├── @types/[email protected]
├── @types/[email protected]
├── @types/[email protected]
├── @types/[email protected]
├── @types/[email protected]
├── @types/[email protected]
├── @types/[email protected]
├── @types/[email protected]
├── @types/[email protected]
├── @types/[email protected]
├── @types/[email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
└── [email protected]
My workaround was to pin express to version 4.17 with npm i express@~4.17.1. That reverted to [email protected]:
[email protected] /Users/michaelperry/Projects/ImprovingUCourseLibrary
├── @material-ui/[email protected]
├── @material-ui/[email protected]
├── @material-ui/[email protected]
├── @testing-library/[email protected]
├── @types/[email protected]
├── @types/[email protected]
├── @types/[email protected]
├── @types/[email protected]
├── @types/[email protected]
├── @types/[email protected]
├── @types/[email protected]
├── @types/[email protected]
├── @types/[email protected]
├── @types/[email protected]
├── @types/[email protected]
├── @types/[email protected]
├── @types/[email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
└── [email protected]
Thanks.
It might also be a Windows thing. This app is running in Azure Web Apps under Windows.
Hm, weird. I don't see that you have statuses installed at all in your list. I was looking at what could have lead to that error and it seems like if statuses doesn't have the expected data.
Here's the tree from npm ls statuses:
[email protected] /Users/michaelperry/Projects/ImprovingUCourseLibrary
└─┬ [email protected]
├─┬ [email protected]
│ └── [email protected] deduped
├─┬ [email protected]
│ └── [email protected] deduped
├─┬ [email protected]
│ └── [email protected] deduped
└── [email protected]
Hi @michaellperry very strange. I haven't actually been able to reproduce the issue, and the small lead I had thought doesn't work with that tree you pasted. Is there a way you can help get a reproduction case I can run to debug? Alternatively, you're always welcome to open a PR with a fix and test (so we don't break again).
I'll put something together. I'll let you know my progress by Monday. Thanks for looking into this, and for creating an essential part of the stack!
@ks221197 I'm still using the workaround npm i express@~4.17.1. I tried to put together a repro, but this only happens under Azure Web Apps for Windows.
TL;DR - upgrade your http-errors to the newest version, and this issue can be probably closed.
Hi guys, I also stumbled upon that error and I might be able to share some more information. Attaching screen from Chrome Dev Tools debugging session. It's a project using React & webpack, [email protected] and [email protected].
It looks like statuses is an object, and accessing it like statuses[code] won't work. A proper way seems to be statuses.message[code]. A quick look into statuses history confirms my findings:
- Remove status[code] exports; use status.message[code]
- Remove status[msg] exports; use status.code[msg]
Looking into the source code of http-errors I see it's already addressed. So this issue happens only when an old version of http-errors is installed alongside with a new statuses.
Facing same issue as @michaellperry with an Azure Web app Had to downgrade express from 4.18 to 4.17
However, I just noticed express released a new version 4.18.2, which includes an update of body-parser 1.20.1, which itself includes latest version of http-errors 2.0.0
Will have to give a try on Azure
I encountered this issue due to:
- A transition from yarn@v1 -> yarn@v3
- Stale nested
node_modulesdirectories leading to Node.js using the incorrect (older) version ofhttp-errors.
What worked for me: erase all node_modules directories and install dependencies from a clean slate.
This looks like a module resolution issue, and not a bug in http-errors.
in its v2 statuses dropped literal notation access via codes statuses['500']
http-errors followed semver, if you're getting this error it's because your node_modules dir is out of sync or otherwise not resolving the dep tree correctly
