-
-
Notifications
You must be signed in to change notification settings - Fork 26.8k
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
CRA and Airbnb require conflicting versions of eslint-plugin-jsx-a11y #3540
Comments
This might be related to #3418. |
We don’t officially support using ESLint configs other than the default one without ejecting. Depending on whether our versions are in sync, it may or may not work, but we won’t commit to always supporting it. In fact I’d say we disagree with some decisions in the Airbnb config and think they’re not great universal rules for people developing React apps. Are there particular reasons you need another config? We’ve tried to include rules that would be valuable for everyone, but exclude any styling rules (so you can use tools like Prettier to automatically format your code). |
If there are specific rules that you feel are missing in our default config, please raise a separate issue and we will discuss adding those. |
(That said you can eject and use any config if that’s your strong preference.) |
Crossposting my comment on #3418:
|
My issue is not with CRA's default eslint config (in fact I think it's great, I just want stricter configs for my projects that are more consistent with my other open source projects that already use shared eslint configs). I personally see CRA as a build tool that shouldn't limit my ability to use other JS ecosystem tools (except for Jest since it's still pretty configurable in CRA and it is sort of a build tool), though I understand there are major debugging benefits to including eslint by default and what I'm asking for may be too difficult to implement. I know this involves more of a maintenance burden, but do you think it would be worth it to use some sort of workaround for eslint users (alternatively I would fork/eject my own shared config based off CRA or use a different tool)? For example, eslint could simply be inlined as a build-time dependency of CRA, which IMO would make the problem vanish (it would not be in the Also I appreciate the advocation of Prettier and while it does make sense for many projects to only use Prettier for styling and only use eslint to catch bugs (like with CRA's default config), there are many useful eslint rules that are outside of Prettier's domain of simply reformatting from the AST while being too opinionated to be moved into CRA's default configs. For example, the |
We're not a boilerplate. 😄
Sure you can! Due to
We're open to making this work by default [installing To be clear: in no way should any custom eslint configuration or rules have an effect on our development or build process; it simply shouldn't break it / prevent the user from having their own lint step. |
You can add such individual rules to your |
@gaearon Could you please tell with which of Airbnb lint rules you disagree? |
At the very least, I disagree with inclusion of the styling rules. I think our users would be better served by tools like Prettier that format the code automatically. I’ve seen beginners learning React spending minutes trying to correct all the irrelevant style nits when they’re just trying to learn some concept. Airbnb config also marks those as “errors” so beginners genuinely think they’re making a mistake somewhere. For comparison, the default config we ship has no style rules. Similarly, Airbnb config considers code uniformity very important so it has rules like “prefer stateless components when not using state/lifecycles”, “use arrows everywhere you can” etc. In my observation this isn’t useful to beginners who copy and paste existing code and expect it to work. It also creates faux “best practices” and dogma in the ecosystem that we don’t necessarily agree with. And even seasoned professionals don’t like to convert functions to classes back and forth because the state ownership is still unclear in the initial project stages. I think developers should be trusted to make such decisions themselves. My observation is that once beginners learn that those rules aren’t really as important as they were lead to believe by blogs/examples/perceived strictness, they start ignoring them altogether, at least during active development. And that’s a shame because ESLint often finds actual mistakes in the code, but being trained by overly restrictive configs, users gloss over them. I know that if we allowed easy customization of the ESLint config that is used for our default lint reporting on I hope this explains it somewhat. That said, the |
Thanks for response! Totally agree with not beginner friendly part (especially styling rules). Forcing user to use ALWAYS(when state/lifecycles not requried) functional components instead of class based could be pain in the neck as well. Anyway for a bit more experienced user could be starting point for adapting some of rules and fit to project code style. Ofc solution could be adding some rules to less restricted config. Anyway 100% agree it shouldn't be a default set of rules. |
- Give up code style linting in favor of CRA's linting methods. For the cause visit (facebook/create-react-app#3540)
This makes it difficult to use CRA with
eslint-config-airbnb@16
, which is very popular with React development.Is this a bug report?
Yes.
Can you also reproduce the problem with npm 4.x?
Yes.
Which terms did you search for in User Guide?
Environment
node -v
: 8.9.1npm -v
: 5.6.0npm ls react-scripts
(if you haven’t ejected): 1.0.17Then, specify:
Steps to Reproduce
create-react-app
.eslint-config-airbnb@16
.Expected Behavior
CRA should support
eslint-plugin-jsx-a11y@16
.Actual Behavior
These errors are mutually exclusive but I'm including them both for convenience and debugging purposes.
The text was updated successfully, but these errors were encountered: