Consider un-deprecating non-error status codes about http-errors HOT 5 CLOSED

We talked about it for 2 years and it's already decided to remove the feature, which is why it is deprecated.

from http-errors.

it's already decided to remove the feature, which is why it is deprecated.

What were the reasons for the decision?

I tried to find discussion / actual reasons for the original deprecation, but there doesn't appear to be any: https://github.com/jshttp/http-errors/search?q=deprecate&type=Issues

Your commit to master deprecating it had no reference to any issues or discussion: 858d082

Unlike deprecating, un-deprecating should not be disruptive. The "deprecation" was only advisory anyway.

from http-errors.

The discussions were on the express and koa gitter channels, I apologize.

The root of the issue is that (1) 200s are not errors and you are misusing the library and (2) it caused endless confusion for koa users because of this. You use case sounds valid for graphql, but thus module is for http semantics not graphql ones. I would suggest use a different lib for better graphql support.

from http-errors.

A user would have to consciously set a 200 status on the error, and so must know what they are doing. I'm not sure why anyone would get confused.

thus module is for http semantics not graphql ones

A GraphQL server sends HTTP responses like any other server. createError is used in 18 places in graphql-api-koa, only one requires a 200 status. It's not appealing to have to migrate to a different lib for this one use, especially when users already have http-errors in their node_modules.

Since the GraphQL use case is solid, and likely to become more common, why not support it? Pretty much the only change necessary is to remove the advisory deprecation notice here.

from http-errors.

Not going to happen, sorry.

from http-errors.