I can't tell if I'm missing the point or this spec is.
To properly handle errors, there needs to be an exhaustive enumeration of the types of errors. This is hard to generalize across all applications and this RFC just sidesteps it entirely.
We don't need yet another way to bundle together a bunch of strings nobody ever reads and that applications will have to parse because there's no error code beyond the woefully inadequate HTTP status. If the app dev has to roll their own enumeration scheme and put this application-level error code in an extension, that's no better than just responding with the JSON they already had.
> To properly handle errors, there needs to be an exhaustive enumeration of the types of errors. This is hard to generalize across all applications and this RFC just sidesteps it entirely.
It's covered by the "type" property of the RFC-defined payload. Type is a globally (URL-based) unique value that your application can either match (and handle) or grab full details (GET url) which can be cached. This allows servers to serve new errors to old clients.
Error handling is underserved in most apps and putting it in a standard increases the probability that npm-install-library developers will do it at all.
To properly handle errors, there needs to be an exhaustive enumeration of the types of errors. This is hard to generalize across all applications and this RFC just sidesteps it entirely.
We don't need yet another way to bundle together a bunch of strings nobody ever reads and that applications will have to parse because there's no error code beyond the woefully inadequate HTTP status. If the app dev has to roll their own enumeration scheme and put this application-level error code in an extension, that's no better than just responding with the JSON they already had.