Skip to content
This repository has been archived by the owner on Jan 21, 2022. It is now read-only.

JavaScript: Do we love AirBnB config? #199

Open
squidsoup opened this issue Aug 19, 2019 · 6 comments
Open

JavaScript: Do we love AirBnB config? #199

squidsoup opened this issue Aug 19, 2019 · 6 comments

Comments

@squidsoup
Copy link
Contributor

squidsoup commented Aug 19, 2019

In maas-ui we've been using the CRA eslint defaults (with prettier), and I must admit I haven't been missing AirBnB config. Is anyone particularly attached to these eslint rules? They require additional configuration which seems a little contrary to the spirit of CRA, but perhaps there are good reasons to persist with using these rules?

Dan says:

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.

facebook/create-react-app#3540 (comment)

Most of Dan's objections however seem to be about making things easier for beginners.

More relevant discussion here:

https://twitter.com/dan_abramov/status/836541301134876672?lang=en

Pinging @barrymcgee @bartaz @Lukewh @huwshimi @Caleb-Ellis @steverydz @hatched for discussion!

@barrymcgee
Copy link
Contributor

My preference is to stick as close to CRA defaults as possible - would happily jettison AirBnB.

@squidsoup
Copy link
Contributor Author

Interestingly, CRA's eslint config is published as eslint-config-react-app so it could be used in non-CRA apps too.

The rules is defines are here.

@bartaz
Copy link
Contributor

bartaz commented Aug 20, 2019

How would CRA eslint defaults work in non React project? Not all of our JS is React, and it wont be for some time.

Having a look at rules they define I don't see why it wouldn't work in 'vanilla' JS project apart from the fact that it probably contains a lot rules and plugins unnecessary in non-React project.
Would it be missing something?

Certainly for React projects we should use as pure React defaults as possible. With features like hooks React introduces very specific linting needs, so to keep up to date we should use tools they recommend.

To be honest, with automatic linting and formatting in editor I forgot what "style" I prefer. I just write JS and let editor fix the issues.

@nottrobin
Copy link
Contributor

Yes I think this sort of asks the question - are we writing and creating standards for JavaScript, or are we just writing React?

For the time being we're definitely writing at least some non-React JavaScript, and the CRA defaults seem a way from being an accepted or even sensible standard in the wider JavaScript community.

So we could have one set of config rules for React apps and another for other JavaScript? That seems like it would make sense to me.

@steverydz
Copy link
Contributor

As long as it's consistent I don't mind what we use, especially since prettier takes care of the formatting. I do think staying close to CRA is a good thing. It seems unnecessary to complicate things with extra config.

I think what @nottrobin suggests about having one set of rules for React apps and one for the others is fine.

@hatched
Copy link
Contributor

hatched commented Aug 20, 2019

I'm not keen on having multiple standards and multiple tools for the same task... ex) airbnb forces destructuring whereas prettier/cra doesn't.

I'd prefer to use a single tool for formatting, which we already have, prettier. And then have the second tool checking for code correctness, eslint. Sometimes this line can be fuzzy but I'd prefer to have minimal rules on the eslint side if we're already using a formatter like prettier.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants