[JS] Updated JavaScript

[dlmr]

This PR is aimed to start a discussion about the JavaScript style guides

This PR has changed the style guides for JavaScript to be based on the widely popular https://github.com/airbnb/javascript with some overrides to match the old configuration a bit better.

The PR will expose 3 separate ESLint configurations that can be used:

• ES6 with React
• ES6
• ES5

The modification in full can be seen below.

{ 
    'indent': [2, 4, { 'SwitchCase': 1, 'VariableDeclarator': 1 }],
    'comma-dangle': [2, 'never'],
    'max-len': [2, 120, 4],
    'no-use-before-define': [2, { 'functions': false }]
}

This PR also adds support for ESLint 2 and that would be the supported version.

I believe it is wise to base the styles on Airbnb since we will then get a lot of rules and conventions for "free" that can really help us maintain better code.

There is two questions to answer here:

• Is it smart to base the configuration on Airbnb?
• Will more overrides be needed?

It also removes the old unmaintained configuration files for JSHint and JSCS.

[mdrobny]

Is airbnb's config so similar to ours (only 4 rules overridden) that we can start using it without fixing lint errors in projects?

[mdrobny]

And did you check if this is working in projects using Babel?

[dlmr]

No, of course not. It introduces several new rules that will make most (all) current project break if they would use the new configuration straight up.

However this changes would be delivered with a major version change, meaning that projects should expect that things will break if they update. And the errors that will occur will be things that when fixed will create better and more maintainable code.

I tested this in a project using Babel 6 along with babel-eslint 6, everything worked fine there.

[voldern]

Could you also mention the largest deviations the airbnb standard has from ours? Or is it just the stuff in override.js that was different from our config?

[dlmr]

That was the only deviation from a local project I had, it just was stricter. However I have not compared the rules against each other in a detailed manner or tested it against more projects.

If you believe that this path is interesting and might be valuable I could look into this in more detail. To note however is that most definitely all projects that today use the VG standard will fail the validation using this, and that is kinda the point in my opinion to be even more strict and get better aid from the tooling with the goal to avoid silly mistakes etc.

[voldern]

If you believe that this path is interesting and might be valuable I could look into this in more detail. To note however is that most definitely all projects that today use the VG standard will fail the validation using this, and that is kinda the point in my opinion to be even more strict and get better aid from the tooling with the goal to avoid silly mistakes etc.

👍 I don't see any reason for not doing this

[andreasrs]

👍 I hope to be linting another project this week, I'll see if I can make some more observations then.

[andreasrs]

Wow, forgot about this one. 😭

I think adopting this standard is the way forwards, it is becoming a solid and widely used approach.

However the landscape has moved quite a lot since April (including eslint versions), so we should probably revise this PR or even create a new one. What do you think? @voldern @dlmr

[Kicu]

@andreasrs Definitely go through new versions of eslint/eslint-plugin-react and check their changelogs :P I bumped this some time ago to be compatible with them, so this PR will probably need revision ;)

[voldern]

However the landscape has moved quite a lot since April (including eslint versions), so we should probably revise this PR or even create a new one. What do you think? @voldern @dlmr

👍