There's some rudimentary validation of the config format. There's static validation via types, and validation of root properties, but there's no validation of the contents of those root properties. This means you could put a config for a non-existent Rule in the rules property, for instance (the configs of existing Rules have their own validation, which it may make sense to hook into--OTOH, it'd be nice to not just throw up our hands if a Rule config is invalid, but the user is running diff, which doesn't use them).
The inspector already consumes ajv to allow rules to define their own option schemas, so maybe that'll work.
It'd be nice to see some runtime validation system that is generated from TS types, so we wouldn't need to duplicate effort here. That said, there's a lot of things you can express in ajv or joi (or whatever) which typescript can't express, so maybe we're all doomed
There's some rudimentary validation of the config format. There's static validation via types, and validation of root properties, but there's no validation of the contents of those root properties. This means you could put a config for a non-existent Rule in the
rulesproperty, for instance (the configs of existing Rules have their own validation, which it may make sense to hook into--OTOH, it'd be nice to not just throw up our hands if a Rule config is invalid, but the user is runningdiff, which doesn't use them).The inspector already consumes ajv to allow rules to define their own option schemas, so maybe that'll work.
It'd be nice to see some runtime validation system that is generated from TS types, so we wouldn't need to duplicate effort here. That said, there's a lot of things you can express in ajv or joi (or whatever) which typescript can't express, so maybe we're all doomed