how do I use .eslintrc for npm start and browser console linting

[ToadJamb]

I am working on a react project that was created with create-react-app. We are using eslint and have added a few tweaks. However, it appears that the browser console (and npm start) use some other configuration. We are seeing warnings about things that do not matter and are 100% style choices. They are coming from eslint rules, but apparently not using our .eslintrc, as they do not show up when we run eslint against the project. How do I get npm start and the browser console to use .eslintrc.json so I can override those warnings?

[Timer]

You can not override the ESLint configuration -- you must eject to do so. You can only supplement it secondarily (with your own linting step).
If you found an scenario where we enforce style, please open an issue and we will consider disabling the rule(s).

[ToadJamb]

I did figure out how to get the warnings to show up in our linting, but obviously turned off that one rule - as mentioned that still only affects running eslint directly and the warnings still appear in the browser.

react/jsx-equals-spacing is a style choice, is it not? I'm not aware of any potential bugs or errors that come out of that. And I could be mistaken, but it looks like that rule originates from this project/team. Why would that ever have been added even as a warning?

One question about ejecting... If we eject, does the browser/npm start then honor our .eslintrc.{js,json,yaml} or do we have to make changes somewhere else?

[gaearon]

We are a little bit stricter in JSX because beginners often misunderstand how it works and produce bad markup when they deviate from the recommended style. We only enforce the parts that are overwhelmingly accepted in the React community, and don’t enforce anything that is debatable (e.g. where to close JSX tags).

[ToadJamb]

When you say 'enforce', you must mean as errors?... These are not errors. They are warnings and they clutter the console for no good reason and make it harder for me to see the messages I'm actually interested in. I can still run my app, I just have to sift through unnecessary warnings.

This warning 'enforces' no spaces even though the style itself allows you to specify a number of spaces. (As an aside, I would contend that it should also support aligning equal signs when the attributes are on multiple lines). However, as I understand it, nothing other than the 0-space setting may be used, as it is baked in.

I have no problem with saving noobs from themselves, but using the .eslintrc provided by the user does exactly that. The users that need the 'help' won't know to change .eslintrc and the ones that do should be assumed to know what they're doing - principle of least surprise. The amount of time I spent tracking this down when the .eslintrc didn't 'just work' for this is really, really annoying and doubly so by the fact that I am not 'trusted' to change it for my own app.

I hacked the module locally to squash this message for myself, but that is very obviously not a long term solution and doesn't save other members of the team from being subjected to it. That's a terrible solution, but the only reasonable way I could get around it, which is just plain silly, not to mention more 'dangerous' than allowing me to just override things in .eslintrc.

[gaearon]

When you say 'enforce', you must mean as errors

No, as warnings. I’d be okay with removing these rules from our config though, I guess, as you’re right these are stylistical rules, and we avoid them. Do you want to send a PR?

They are warnings and they clutter the console for no good reason and make it harder for me to see the messages I'm actually interested in

This is a completely different problem (and a bug). When we display ESLint errors (and break the build), we should hide the warnings. I’ll file a new issue for this 😉

[gaearon]

Filed #2056 and #2057.