My thoughts after 4 months of using this library

[tyleralbee]

This library is my favorite abstraction on top of express. I originally went looking for a more coherent way to integrate validation into the request lifecycle. In giving this library a try, I ended up with more than that. The incredibly dedicated and talented maintainer has clearly put thought into where express may fall short (for lack of better phrasing; it is OK that express is unopinionated).

About 4 months ago, I posted a thread looking to gauge the long-term viability of using this library. On that post, and just about every post/issue I have seen, the maintainer responds just about immediately. Most maintainers of OSS go unthanked, and I wanted to start off by saying thank you.

For anyone considering this library as I was, I want to share some of the things I love about using this library. After that, I will give a couple suggestions.

This library is great because:

1. The abstraction for defining request handlers is intuitive, powerful, and opinionated in the best way possible.
2. Server configuration is flexible to extend but is designed with sane defaults that work out of the box.
3. It has some of the best type-safety I have ever seen, specifically, with respect to request handlers.

I believe this library is an example of when opinionated is done right. A small thing that I love is the choice made to force best practice in response structure out of the box. But, over everything else, I believe the way this library ties validation into the request/response lifecycle is its greatest strength.

There are always things that can be done better. Here's what I would like to see (I am happy to help where I can):

1. There should be a way to support the project monetarily
2. More descriptive development error messages (specifically when errors happen in request handlers)
3. A clean way for the endpoint abstraction to incorporate non-200 HTTP responses in a similar manner to how 200 responses are handled

Thanks for the hard work.

[RobinTail]

Thank you for the feedback, @tyleralbee , I highly appreciate it.

2. More descriptive development error messages (specifically when errors happen in request handlers)

Could you please clarify what kind of errors is it about, some example would be helpful.

3. A clean way for the endpoint abstraction to incorporate non-200 HTTP responses in a similar manner to how 200 responses are handled

Glad to inform you, that I'm going to make it cleaner in the upcoming v20. Here is an example. In case you meant something else, please clarify (with an example) what exactly should be made cleaner.

new ResultHandler({
    positive: (data) => ({
      statusCodes: [201, 202],
      schema: z.object({ status: z.literal("created"), data }),
    }),
    negative: [
      {
        statusCode: 409,
        schema: z.object({ status: z.literal("exists"), id: z.number().int() }),
      },
      {
        statusCodes: [400, 500],
        schema: z.object({ status: z.literal("error"), reason: z.string() }),
      },
    ],
    handler: () => {},
});

[tyleralbee]

Great, I am looking forward to trying out v20!

Next chance I get, I'll give you an example of an error message I feel is misleading. It would be best if I had a real example, so I won't go into detail without one. As I hopefully made clear, this kind of issue is not common. By and large, I have had a wonderful experience.

[RobinTail]

You can already try it, beta.3 is published, @tyleralbee

[tyleralbee]

You can already try it, beta.3 is published, @tyleralbee

Are you looking for people to try this out before full release? I may wait for the official release if it doesn't need testing.

[RobinTail]

There should be a way to support the project monetarily

Good news, @tyleralbee , now you can:

1. https://github.com/sponsors/RobinTail
2. https://buymeacoffee.com/robintail