eslint-plugin-flowtype
eslint-plugin-flowtype copied to clipboard
"indent" rule
ESLint's indent rule doesn't seem to apply to Flow types. Example:
type Foo = {
a: string,
b: number,
}
@gajus Help wanted? I've contributed to eslint-plugin-react and wouldn't mind taking a stab
@gajus Help wanted? I've contributed to eslint-plugin-react and wouldn't mind taking a stab
Go for it!
@gajus Cool! Because I'm not extremely confident working with eslint rules yet, to start do you mind if I post ideas and questions here before starting any development?
To make sure we're on the same page, I believe the flowtype indent rule should work alongside the base indent rule, rather than reimplementing base indent rule with additional functionality for flow types. Does that sound right?
Next topic, from quickly scanning some existing eslint flowtype rules, I believe these are the two element types we would use to discover opening of relevant structures in type definitions:
-
ObjectTypeAnnotation
-
TupleTypeAnnotation
The default eslint indent rule has a ton of options. I believe our rule only needs to support some similar functionality of arrayexpression
and objectexpression
. Is that correct?
- https://eslint.org/docs/rules/indent#arrayexpression
- https://eslint.org/docs/rules/indent#objectexpression
Are there any features / options that you would consider "must-have" for an initial version?
Thanks for your insight.
To make sure we're on the same page, I believe the flowtype indent rule should work alongside the base indent rule, rather than reimplementing base indent rule with additional functionality for flow types. Does that sound right?
Not sure what do you mean by this.
It would be a rule entirely implemented in https://github.com/gajus/eslint-plugin-flowtype codebase.
Next topic, from quickly scanning some existing eslint flowtype rules, I believe these are the two element types we would use to discover opening of relevant structures in type definitions:
Makes sense.
The default eslint indent rule has a ton of options. I believe our rule only needs to support some similar functionality of arrayexpression and objectexpression. Is that correct?
Looks correct to me.
Are there any features / options that you would consider "must-have" for an initial version?
Hard to comment without seeing the first MVP. Start with the primitives. Test cases will reveal all the edge cases.