Open dylanpyle opened 8 years ago
Their rules are pretty much the gold standard. 👍 👍 👍 👍 👍
For context, one of the things that prompted this was that our current ruleset only works with eslint v1 - the current version is v3, so there would still be a bit of effort involved with getting us back up to the current state of things if we don't go this route.
@Shyp/platform — thoughts on this? This stuff has caused a decent amount of debate in the past, I'd kinda like to just be done with it. Here's the config I'm using for some personal stuff, for reference.
@dylanpyle This seems reasonable to me. I'd be curious to see the diff on shyp.com to accommodate the new rules.
🍧
@benbuckman Here's the current set of failures — I didn't put in the time/effort to start whitelisting rules:
edit: redacted, contact me for the link
The vast majority are the same few things we can easily add exceptions for (e.g. trailing commas, singlequotes), since we have a big corpus of code that contradicts them, and have intentionally chosen to style stuff that way.
There are some issues related to the babel
build process - e.g. the import paths failing, syntax errors parsing the propTypes
syntax. For these, we could reintroduce the current 'run it through babel' build step, which is fine but a bit slow — in the slightly longer term I'd like to move away from the >ES2015 feature set altogether though, which would clean those up (we're only using a couple of features, so writing a script/macro to fix those should be straightforward).
That only leaves a few substantive ones - things like the order of imports, not writing class instance methods that don't refer to this
, some stylistic issues with arrow functions, etc. This is the kind of stuff I'd love to just defer to their choices on — preferring 'do it a certain way that we may not be 100% sold on' over 'do it both ways, or neither'.
👍
I've been using eslint-config-airbnb recently — it seems like it matches our rules pretty closely, and it's a whole lot stricter about a lot of things, plus well-maintained as new rules are introduced.
I haven't had much time to keep this curated, and I think it might make sense to just remove the bulk of our custom rules, and just extend that set instead. I haven't noticed many direct contradictions with our code style, but lots of clarifications of cases where we use two equivalent patterns and should just pick one.
Pros:
Cons: