Adopt and enforce a common ES6 coding standard

[rod-glover]

Code style in this repo is both internally inconsistent and inconsistent with the most widespread JS style standards. There are several places where the code does not even follow elementary problem-preventing conventions, such as using === and !==.

Suggest we adopt a style standard, a linter to check it, and a policy or tools to enforce it. I recommend the following:

ESLint:

• is widely used,
• has plugins for the most widely used editors and IDEs,
• has integration (i.e., automatic checking) with GitHub,
• includes a tool that will automatically fix failures for some common rules (mostly whitespace, but more)
• has a special set of React specific linting rules for ESLint available

(ESLint plus the react plugin is installed on my IDE and has proved extremely useful for helping me spot possible errors and stick to React best practices. It's also calling out our code A LOT.)

I'd be happy to lead the effort on this, including applying the auto-fix tool.

[corviday]

Seems like a good idea. I previously tried to use JSHint with the CE frontend code, but it didn't understand React or JSX and threw up so many bogus JSX-related errors I gave up on it.

[jameshiebert]

I support this as well. We actually do have a command in the repo to configure and run eslint.

But as you have pointed out, the problem is that it's not run automatically and regularly with each commit, so the standards aren't actually enforced.

[rod-glover]

We also have two git hooks defined, one to run eslint before commit (using the command you noted), and the other to rebuild node_modules whenever a new commit is checked out.

They are inactive because they are not in the .git/hooks directory (instead in git/hooks). It would be easy to move the eslint hook into .git/hooks.

I'll do that locally to check whether it works (looks like it should). If that seems good, I'll post a PR to enable the eslint githook.

[jameshiebert]

They are managed in git/hooks because one cannot place things in the .git directory to be managed by the .git directory :) So it's up to whoever checks out the repo to do the manual step of copying them over (or symlinking them into .git).

[jameshiebert]

We could do something like this...

[rod-glover]

Small complication: The .git subdirectory is ignored and is not part of the repo. (This is standard, and widely noted in discussions of git hooks.) Therefore the easy path is also voluntary, i.e., not externally enforced: Copy the hooks you want activated into your local .git/hooks directory. I will set this up (a slight bit of additional scripting in git/hooks.)

Strong enforcement on the server side is kind of a pain. But there is a simpler form of enforcement we can employ: Add a line to .travis.yml to run eslint as well as the unit tests. If eslint fails, the branch is not considered passing. There would be a little additional scripting to do this, but the outline of what's needed is in existing examples.