-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider auto detecting react and adding standard-react rules #20
Comments
Also, see #16 for more background discussion. |
Why it would not conform to standard? All standard rules would be preserved, you'd be adding something on top of standard rules only |
standard test.js -> 0 errors ^ that's what I mean by not compatible |
Well, my vote is to provide good linting defaults, not 100% match with standard.js |
I'm not saying we shouldn't deviate. Just need to figure out the approach and where to draw the line. For example, there exist other non style linting tools, such as https://github.com/saadq/lynt. Why is that one different from Healthier? I suppose, Healthier has editor plugins and another thing is it conforms to (or at least originates from) the standard. Standard just happened to be a good base. Anyway. |
lynt seems like solid alternative for react stack. maybe you could join efforts, or take lynt config and sprinkle extra stuff on top of it, or just expand on it. I really like that lynt agreed to introduce and auto detection of jest / flow / react / typescript / vue saadq/lynt#41 |
btw. I like healthier approach of merging different plugins better - lynt needs to maintain these configs while you can focus on creating nice umbrella package As for prop-types rule I agree it is too strict, you could extend https://github.com/facebook/create-react-app/tree/master/packages/eslint-config-react-app instead or make this rule a warning and introduce another IMO it would be great if healthier adapted "zero config approach" for developers that use popular libraries and tools like react / vue / jest etc. |
Added this feature to [email protected]. If React is detected, healthier will turn on extra rules ( |
The main reason I haven't done this yet is because it would make healthier incompatible with standard. Up until now, anything that conforms to standard was also conforming to healthier.
But maybe that's not a big deal. It's all about good defaults, good user experience, etc.
The other reason is that prop-types validation is a bit invasive, I usually don't use it in my apps. So again, I don't want to be caught in the position of making decisions on rules without sort of leaning on standard, where people spend more effort arguing for each rule, etc.
The text was updated successfully, but these errors were encountered: