When I teach treating errors as values, and myself wonder where an error falls on the spectrum of domain vs infra vs panic, what the user and/or developer can do about it, as a UI guy at heart, I always come back to how you display that.
I wanted to cover how you’d do that in Linting because now that LLM’s are showing us how “fuzzy things can still give definitive steps to help, with options”
The cop-out is to be like “build it like Elm… I mean Rust even copied that style so it must be good”.
However, I’ve been reviewing JavaScript Linters lately, and the spectrum is pretty deep, but Flint in particular has a nice Elm-like error in interactive mode.
tl;dr; on Flint, it’s a hybrid JavaScript/TypeScript linter: the core and rules are written in TypeScript to make it easier to allow open source contributions, but plugins can be written in native code, like Biome/Oxlint are doing.
Here’s a screenshot attached of Flint finding a linting failure on a loop using for, citing what file, why the linter failed for this particular bit of code, a suggestion of what to do, and a link to learn more. That’s … amazing.
Now imagine if _every_ domain and infrastructure error you created had even one tenth of this meat embedded inside it, with ability to print for non-prod/local dev logging scenarios? Always inspiring to me to see how people interpret errors, specifically linter errors which can be quite fuzzy/squishy, open to interpretation, but need some kind of actionable step to fix it. I really like Flint’s approach here.
Leave a Reply