Inconsistent error property enumerability

[jaydenseric]

You would expect these usages to log identically:

import createError from 'http-errors'

console.log(
  JSON.stringify(createError('Message 1.')),
  JSON.stringify(createError(new Error('Message 2.')))
)

They actually output this:

{"message":"Message 1."} {"expose":false,"statusCode":500,"status":500}

For context, I am attempting to do snapshot testing of errors that have been created various ways and am having many surprises.

[jaydenseric]

If it helps guide what the right behavior should be, the JSON representation of a normal Error instance is {}:

console.log(JSON.stringify(new Error('Message.')))

Consistency with native errors might make sense, although for the purposes of snapshot testing I wish all of the properties were enumerable.

[dougwilson]

Ah, that's a good point. I can see either way, but it makes sense that it should be consistent.

[jaydenseric]

Related past discussion: #20

[dougwilson]

So the issue is that the properties you are getting in the output are just the ones we are touching inside the factory and JSON.stringify ignores properties on the prototype.

All the properties we add are enumerable so it seems like the issue here is that Json.stringify doesn't print out properties on the prototype, hm... I'm not sure what a good solution would be.

Does anyone have some thoughts on this?

[jeanbaptiste-brasselet]

Actually for some reason message is now enumerable when for a classic error it is not. And statusCode is not enumerable.

This is really weird, and it seems to have been done because someone is trying to JSON.stringify it. But it should not be the problem of http-errors

[dougwilson]

Hi everyone, as an update, the 3.0 release will address this by setting all properties as non-enumerable, which matches how ECMA-262 works with errors: https://tc39.es/ecma262/#sec-error-message

[mahmoodhamdi]

For anyone landing here while this is still open — I've been working around this inconsistency in my Express error handler by using a helper that normalizes the serialization:

function serializeHttpError (err) {
  return {
    status: err.status,
    statusCode: err.statusCode,
    message: err.message,
    name: err.name,
    expose: err.expose
  }
}

The root cause is that when createError(status) is used (no existing error passed), the error is created via the named constructor (e.g., NotFound) which uses Object.defineProperty to set message as enumerable. But when createError(existingError) is used, the properties are set directly on the existing error object, and message stays non-enumerable (native Error behavior).

Looking forward to the v3 fix mentioned by @dougwilson where all properties will be non-enumerable to match ECMA-262. That's the right call — it aligns with native Error behavior and makes JSON.stringify output consistent (empty {} by default, explicit serialization when needed).