CRA and Airbnb require conflicting versions of eslint-plugin-jsx-a11y

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?

• Airbnb
• accessibility
• a11y

Environment

1. node -v: 8.9.1
2. npm -v: 5.6.0
3. npm ls react-scripts (if you haven’t ejected): 1.0.17

Then, specify:

1. Operating system: macOS 10.13.1

Steps to Reproduce

1. Install create-react-app.
2. Install 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.

npm WARN eslint-config-airbnb@16.1.0 requires a peer of eslint-plugin-jsx-a11y@^6.0.2 but none is installed. You must install peer dependencies yourself.
npm WARN eslint-config-react-app@2.0.1 requires a peer of eslint-plugin-jsx-a11y@^5.1.1 but none is installed. You must install peer dependencies yourself.

[gaearon]

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 npm start, many open source examples using CRA will be pressured into adopting Airbnb config because it’s popular and many experienced folks feel that it validates their coding style. I think that overall even allowing a restrictive config like this to be used in CRA terminal/console lint output will hurt the beginner experience with those examples, and ultimately it hurts React learning and adoption.

I hope this explains it somewhat.

That said, the a11y plugin version has been bumped in the latest react-scripts@2.x alpha so you can try it: https://github.com/facebookincubator/create-react-app/issues/3815.

[gaearon]

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).