TJ
TJ
Currently it is, but that might change. It's a tough call, it sort of depends on the situation so maybe there needs to be an opt-in. Always great to hear...
My main worry is running something in the build hook that is meant more for a deploy in CI etc. In the case of Go for example it builds a...
👍 I think this makes sense as well, if you have something like "yesterday at 5pm", you'll still get the seconds of `now`, at least in my case (query range)...
Custom rules sounds reasonable to me, I didn't look at how they're implemented yet but I'll take a look!
It's a little half-baked at the moment, I'm thinking a `./errors` pkg or similar (maybe still root) would be nice. Ideally all of the http status codes not just the...
That could work, I'll give it some thought, in Go-land at least it would be more idiomatic to return `error` (unfortunately haha). I guess it either ends up being awkward...
True true, I did want to support arbitrary error context, just some object or whatever you want along-side `type` and `message`, but there's no reason that errors need to be...
It's totally doable in Go, but definitely not idiomatic, you pretty much never see a single interface value returned which acts as a union for errors as well. Maybe that...
Hmm I guess worst-case this package could just have an implicit type for network errors. I'll probably worry more about error handling in a month or two to polish this...
Awesome! I'll take a look soon