SebastianVerified account

I haven't posted anything about Rome in a while so here is what I worked on this evening. These are more error messages. It's obviously not all I'm working on but it's the easiest thing to tweet and discuss.

I have developed a vendetta against poor error messages. I have discovered that validating input like: function isValid(input: string): boolean; Is almost always bad. function getInvalidRange(input: string): undefined | [number, number]; Is way better.

What does that actually mean? Actually pointing to the specific range and location of invalid input rather than "there is an error in here somewhere".

Rome ingests package.json files and performs some normalization and validation. One of the fields is name. When you use a package.json name in npm or yarn that is invalid, it will just yell at you. Rome points to the exact location with some possible hints. Examples:

Curious to see how you keep these organized and maintainable. It feels like a *lot* of highly specific code maybe?

Not really. You queue up errors, always recovering from them by normalizing input etc. Then you have a boundary where you either dump the errors and stop, or write the normalized values somewhere when there's a --fix flag. Easily abstracted.

No, I get that. My question was more around the multitude of possible errors. I imagine there's a separate module for every single test, so how will maintainers know that the validator they want to add exists already? Documentation discipline? Kinda reminds me of ESLint rules.