Better handling of invalid rule configuration options #4280
Comments
I did some trial by error for this validation feature. I found that the method to validate the options itself wouldn't be that hard to implement. For example jsonschema seems suited for the job function validateRulesOptions(
rules: Map<string, Partial<IOptions>>,
rulesDirectory?: string | string[],
): Map<string, Partial<IOptions>> {
const validator = new Validator(); // import { Validator } from "jsonschema";
rules.forEach((ruleOptions, ruleName) => {
// TODO: Make sure ruleSeverity is not "off" and ruleArguments aren't undefined
const Rule = findRule(ruleName, rulesDirectory);
// TODO: Make sure Rule is defined and has metadata
if (Rule.metadata.options === null) {
if (ruleOptions.ruleArguments.length !== 0) {
// TODO: Print warning that given rule doesn't expect any options
}
return;
}
const validationResult = validator.validate(ruleOptions.ruleArguments, Rule.metadata.options);
if (!validationResult.valid) {
// TODO: Print warning that given options don't match rule's JSON schema, maybe also print validation errors
}
});
} The tricky part is how the JSON schema for the options is currently written and how the options are written in tslint.json. The rule options: {
type: "string",
enum: [OPTION_ARRAY, OPTION_GENERIC, OPTION_ARRAY_SIMPLE],
}, But since ruleArguments are always arrays, the option will be something like |
@cheeZery do you pretend to submit a PR with this? |
@rafaelss95 actually no, I'm not :) since this issue still got the tags "In Discussion" and "Needs Approval". |
💀 It's time! 💀TSLint is being deprecated and no longer accepting pull requests for major new changes or features. See #4534. 😱 If you'd like to see this change implemented, you have two choices:
👋 It was a pleasure open sourcing with you! If you believe this message was posted here in error, please comment so we can re-open the issue! |
🤖 Beep boop! 👉 TSLint is deprecated 👈 (#4534) and you should switch to typescript-eslint! 🤖 🔒 This issue is being locked to prevent further unnecessary discussions. Thank you! 👋 |
Continuing discussion in #4206: how should rules display that their configurations are invalid?
Right now, as @cheeZery suggested, they can use the
showWarningOnce
strategy and not run. Should there be a standard utility for this?More grandly, what if there were a system to validate options once per rule on startup? Rules already have JSON schemas specified, can we use it to remove the burden of validity checking from each rule?
The text was updated successfully, but these errors were encountered: