arendjr

They’re included in the beta!

Specifically, you can create GritQL plugins for custom linter diagnostics. There’s certainly more we’d like to do on that front, but we’re first going to see how these are being received to decide where to prioritise next.

I don’t have Nix experience myself, but what would it take to be better supported there? I think we’d be open to PRs for that ☺️

We don’t currently publish to Crates.io, but we do have CI integrations that can install without needing NPM.

Formatter and linter in one even :) I’ve updated the message at the top.

I think it’s the latter. I once had to take care of a sick friend who was pretty much puking her guts out. Her moans sounded arousing. Of course she wasn’t intentionally doing that, it’s just our own male brains playing tricks on us.

I’m making a case for custom codes, not for using a 200 status code with it. My reply said the 200 didn’t make sense.

Of course once you use custom codes, the actual HTTP status codes do become less important, because there’s some redundancy there. That’s not an argument to do it wrong, but it is an argument that accurate HTTP status codes are less of a priority. So understandably some people will take shortcuts.

Apparently you find this very frustrating, but in the end it’s just an implementation detail. But it also sounds like you’re more frustrated with the service API as a whole than the fact it uses custom error codes specifically, so I’m just going to leave it at that.

I’m not arguing against that. Merely providing some counterweight to the idea that the author was “flinging shit in the trenches” 😅

I found the title of that section slightly triggering too, but the argument they lay down actually makes sense. Consistency helps you to achieve correctness in large codebases, because it means you don’t have to reinvent what is correct over and over in separate pockets of the codebase. Such pockets also make incremental improvements to the codebase harder and harder, so they do come back to bite you.

Your example of vendors doesn’t relate to that, because you don’t control your vendor’s code. But you do control your organisation’s.

Well, looking at your example, I think a good case can even be made for it.

“s23” doesn’t look like an HTTP status code, so including it can make total sense. After all, there’s plenty of reasons why you could want custom error codes that don’t really align with HTTP codes, and customised error messages are also a sensible use case for that.

Of course duplicating the actual HTTP status code in your body is just silly. And if you use custom error codes, it often still makes sense to use the closest matching HTTP status code in addition to it (so yeah, I agree the 200 in your example doesn’t make a lot of sense). But neither of those preclude good reasons for custom codes.

Oh, and then I pair it with a very boring Dell mouse for extra style.

Ha, I better not tell you about the Apple Keyboard I use with my Linux laptop then. Don’t like macOS much, but I love their flat keyboards.