Update `http-errors` to v2

[jamesopstad]

Fixes https://github.com/jshttp/http-assert/issues/19

This updates http-errors to v2. Koa depends on both http-assert and http-errors so this ensures that http-errors resolves to the same version. Currently, users end up with two different copies of http-errors, which can lead to some strange behaviours. Additionally, use of eval was removed in the http-errors upgrade (via an upgrade to depd) so this will resolve security warnings and compatibility issues with Cloudflare Workers.

[jamesopstad]

@jonathanong I see you are a member of the org and a contributor to Koa. Are you able to review and release this?

[jamesopstad]

Thanks @jamesopstad for helping the project! I just made a small change in 1473565 for compatibility with [email protected] 👍

Thanks @UlisesGascon. Is there any chance we could bump up the priority for getting a release out? This is blocking compatibility with some of Cloudflare's developer tools, which is impacting users.

[UlisesGascon]

I think that we can try to target a release for Monday 15th... otherwise next train will be on January. I will book some time to prepare the release :+1:

[UlisesGascon]

IMO this changes behavior in a breaking way... specifically when msg is undefined but opts is provided, those props no longer make it into the created error. That was previously supported, so users relying on that would see a regression.

From assert(false, 500, undefined, {foo:1}) -> createError(500, undefined, {foo:1}) to createError(500) :thinking:

WDYT @jonchurch @wesleytodd ?

Also... if we consider this as a major, do we want to introduce any additional change? Should we update Node compatibility too?

For additional context see http-errors changelog

[jamesopstad]

IMO this changes behavior in a breaking way... specifically when msg is undefined but opts is provided, those props no longer make it into the created error. That was previously supported, so users relying on that would see a regression.

Could we update this PR to make the change non-breaking by adding logic for this scenario? That would be preferable because otherwise importing libraries will need to upgrade and may consider that they themselves can't support this before a major release.

[jamesopstad]

@UlisesGascon I've pushed some changes that correct the behaviour change and simplify things and I've added a test for this. I believe this means that there's no need for a new major version. Please take a look when you can.