I spend some considerable time reverse engineering the module, so I
thought I’d write the documentation I would have liked to see.
The strategy here is that a user not necessarily has insight into how
servant works internally, or even how to write complex servant routes,
they just want to generate a list of endpoints and convert the `Req`
type into e.g. generated code in $language. Thus, they need to know
the semantics of all fields of Req, how they interact and how they
relate to a plain http route.
I made sure every `f` is replaced with `ftype`, so we have one
conventional way of referring to the foreign type argument everywhere.
Some enums are not set at all, they are marked as such.
`_reqBodyContentType` introduces a major restriction of the module, so
that is mentioned in the documentation for now, until the time it will
be fixed.
A few TODO’s describe places where types don’t make sense but would
introduce API-breaking changes, so these should probably be
simplified,
but bundled in one go.
The imports were ordered in the worst possible way, with all
undocumented small type definitions coming first and the actual meat
of the module coming at the very end, mixed in with irrelevant
functions.
This inverses that toxic ordering, showing the main function
first (`listFromAPI`) and then the main data type (`Req`) and the main
class (`HasForeignType`).
- Setup a basic CI based on GitHub actions, with a somewhat limited build matrix.
- Disable cookbook/testing, because servant-quickcheck doesn't build anymore.
- Disable servant-docs on Cabal build, because of some test failures
- The order of some JSON fields seems to be reversed in the output, need investigation.
- Fix test failures in servant-http-streams when `localhost` points to an IPv6 address rather than 127.0.0.1.
