Skip to content
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

Closed
KidkArolis opened this issue Feb 5, 2019 · 8 comments
Closed

Consider auto detecting react and adding standard-react rules #20

KidkArolis opened this issue Feb 5, 2019 · 8 comments
Labels
bug Something isn't working enhancement New feature or request question Further information is requested

Comments

@KidkArolis
Copy link
Owner

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.

@KidkArolis
Copy link
Owner Author

Also, see #16 for more background discussion.

@KidkArolis KidkArolis added question Further information is requested enhancement New feature or request bug Something isn't working labels Feb 5, 2019
@sheerun
Copy link

sheerun commented Feb 7, 2019

Why it would not conform to standard? All standard rules would be preserved, you'd be adding something on top of standard rules only

@KidkArolis
Copy link
Owner Author

standard test.js -> 0 errors
healthier test.js -> 3 errors

^ that's what I mean by not compatible

@sheerun
Copy link

sheerun commented Feb 7, 2019

Well, my vote is to provide good linting defaults, not 100% match with standard.js

@KidkArolis
Copy link
Owner Author

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.

@sheerun
Copy link

sheerun commented Feb 12, 2019

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

@sheerun
Copy link

sheerun commented Feb 12, 2019

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 --warnings flag that shows them. I think you can decide to include / exclude some rules if there's good reason, after all it's opinionated package.

IMO it would be great if healthier adapted "zero config approach" for developers that use popular libraries and tools like react / vue / jest etc.

@KidkArolis
Copy link
Owner Author

Added this feature to [email protected]. If React is detected, healthier will turn on extra rules (standard-react, react-hooks and some from react-app). Auto detection is not done in eslint-config-healthier but there you can turn same rules by extending healthier/react in addition to healthier.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working enhancement New feature or request question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants