SebastianVerified account

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.

The validation and normalization is the same code. I don't really understand the question. There isnt some special set of validators.

I mean "Redundant @ in org name" is one highly specific assertion. I assume there are going to be *tons* like that soon, so my concern is around organizing them and keeping them discoverable. To be clear, I'm totally not saying specificity is a bad thing.