Optional Addition of Test Coverage for Consistency

[seanmhanson]

I was thinking about this because on an internal project, we have lightweight test coverage to ensure that modifying our set of errors is always consistent with the others.

Pros

• reduces the burden of new/existing contributors smoke testing
• can be part of git hook to ensure broken changes aren't committed
• increase in code will be for dev-deps only

Cons

• possibly a major change, depending on if the directory structure changes, etc.
• setting up jest (or an equivalent) can be time consuming ditto typescript
• may increase complexity of a 2.x.x version in the future

Coverage

If implemented, these would be my suggestions for things to test:

• index.js (single source of truth)
  • all status names have a corresponding code and reason
  • given any code, we can look up the reason
  • given any reason, we can look up the code
• index.d.ts
  • any exports and/or enums are kept in parity with index.js
• README.md
  • the table of codes is kept in parity with index.js
  • the table of codes is sorted by status code

I realize these aren't anything particularly pressing, but might be a nice to have / honestly I'd consider working on it later because I have been wanting excuses to do more with tooling and workflows

Thanks!.

[prettymuchbryce]

🙏