refactor(rule): rework prefer-inline-decorator to accept options #794
Conversation
|
This will require more time for review. I'll try to push it sometime next week. |
| return super.isEnabled() && this.areOptionsValid(); | ||
| } | ||
|
|
||
| private areOptionsValid(): boolean { |
There was a problem hiding this comment.
If the options are not valid, we should probably throw an error. Wondering why we're unable to validate directly with the schema? Doesn't tslint do this already?
There was a problem hiding this comment.
So... this is something that I was about to propose to you: use a lib (something like https://github.com/epoberezkin/ajv) to validate JSON schemas.
AFAIK, there's no in-built validation for tslint. All the checks are "hard-coded" in the isEnabled method from https://github.com/palantir/tslint/blob/4b8bbf66b7fe7f49122debdeb02164e045b3a691/src/language/rule/abstractRule.ts#L49
There was a problem hiding this comment.
JSON schema validation would be great. We do this in the CLI for builders' arguments.
src/preferInlineDecoratorRule.ts
Outdated
| optionKey: OptionKeys | ||
| ): ReadonlyArray<string> => { | ||
| return decorators | ||
| .map(decorator => getDecoratorName(decorator)) |
prefer-inline-decorator:getDecoratorName, which throws an error if you try to get a name of adecoratorthat isn't a call expression);fixis applied to a property/method with multiple decorators, it just keeps the first decorator (from top) and aligns the property/method with this remaining decorator. I've opted to remove thehasFixoption, because it would be a pain to handle all possible cases correctly.