Consider using restify/errors as base

[jfexyz]

The restify/errors project seems to have some of the same underlying goals (creating standard representations for common HTTP/REST errors) and includes support for many more errors than Feathers includes by default.

If FeathersError extended RestError/HttpError, it might provide even more options for end users.

Update: To be clear, I haven't thought about how this might work, but one of my first thoughts in moving from a custom Restify app to Feathers was that I missed the more complete errors functionality.

[ekryski]

Looking at it quickly I'm not sure that I would inherit from that lib directly because we have some stuff in here that makes it easier to handle database errors. That being said, there definitely some REST errors that we should add.

We could also potentially do what they do in Restify and programatically grab the errors from the node http module, although I'm a bit hesitant to do that necessarily because we also use feathers-errors on the client and React Native.

Good suggestion!

[jfexyz]

Well, I didn't mean "inherit from that module" as "replace this module". The handler function would still be here, for sure. I meant FeathersError could extend the restify errors classes. That way you would benefit from a lot of the extras they have (more errors, ability to combine errors, etc), while not needing to maintain yet another semi-canonical list of of http errors.

[daffl]

I like the idea. The more - good and proven - code we don't have to write and maintain the better. As you pointed out error to HTTP code mapping has probably been done a hundred times already.

I did have a quick look and it looks like the module is pulling in at least all of lodash and the http module. As @ekryski mentioned, we're trying pretty hard to minimize external dependencies to keep the client side Feathers build as small as possible (currently everything weighs in at around 20k minified and gzipped). That doesn't necessarily justify maintaining our own error module but may require some additional work contributing to the one we decide to use.

[ekryski]

Yes I agree with @daffl completely. I'll add that right now it's a pretty low priority (at least for me) but if "someone" is up for a PR that also allows us to still use feathers-errors client side it'll definitely get merged. The less we have to write ourselves the better and I absolutely see value in being able to use the restify errors.

[jfexyz]

Yep, I totally agree with minimizing external dependencies for the client side. I'll look into upstream patches to minimize those...

[ekryski]

👍

[daffl]

I'm going to close this one for now. Thanks again for the suggestion @joshuajabbour. Looking over it again, I think migrating the Restify errors to work on all platforms will be more work at the moment than maintaining our own.