As a cli tool to support testing of endpoints: very nicely contained and concise.
As a library for use in test code: I'm yet to try and use it this way but looks fun to use!
So far fetchbook only works as a cli. I have not yet found a use case for it to also work as a library.
I have built a similar tool, but more geared toward speed and CI/CD pipelines (check my submission history if you really want to know, don't want to detract from this project in any Way).
This looks like a very "scratching your own itch" sort of a project. What led you to build this? Why does this meet your needs while other things have failed (to the point that you decided to build your own)?
1. I love building things, I can't help it.
2. I don't enjoy using markup languages mainly because of lack of autocomplete and difficulty to support more complex use cases. By using typescript fetchbook suddenly inherits all it's powers and can be more easily customized.
3. By piggybacking on top of the Request Web API (https://developer.mozilla.org/en-US/docs/Web/API/Request), I don't have to define custom ways to define requests. Also if you know how do fetch on JS/TS you can grasp fetchbook in less than 5 minutes.
Oh and fetchbook is also ready to be used in CI, I run tests for fetchbook in GitHub actions, which are actually fetchbook stories themselves.
I am very skeptical of this. Could you convince with me with more specific details?
I cannot say that fetchbook would not have been possible without bun, but I am fairly confident it would not have taken me 3 days from idea to this HN comment.
Maybe give it a go?
Edit: maybe using deno would have been as easy... but I chose to try bun and I felt in love with it instantly.