Add support for JavaScript coding standards

[stevegrunwell]

WordPress has an official .jshintrc file and PHP_CodeSniffer can be configured to run it automatically, we just need to put those pieces together so JavaScript can automatically be linted/hinted/otherwise checked.

[dana-ross]

One of my projects uses JSCS. It would be great to be able to choose JSHint or JSCS.

[ghost]

One of my projects uses JSCS. It would be great to be able to choose JSHint or JSCS.

No one should be using JSCS or JSHint these days. Those tools are dead, and have been replaced by ESLint and JavaScript Standard Style.

The Linux philosophy is that a tool should be good at one thing and one thing only. Adding JS linting to enforcer will only conflate the usefulness of other existing tools which already do this handily.

[stevegrunwell]

No one should be using JSCS or JSHint these days. Those tools are dead, and have been replaced by ESLint and JavaScript Standard Style.

While it's great to be able to use ESLint or JavaScript Standard Style on new builds, that's not always an option (especially with existing projects and/or in agencies). This is compounded by the fact that WordPress has its own JavaScript coding standards and, as WP Enforcer is meant to be a tool to aid in writing to the WordPress coding standards, the checks that it uses must adhere to what's set forth by the WordPress project.

@JHabdas raises a good point about the conflation of responsibilities, but I'd counter with the thought that WP Enforcer's goal is to automatically install git hooks to prevent non-standards-compliant code from being committed to a WordPress project; PHP was a logical starting point, but both JavaScript and HTML feel very much in the scope of this project.

[ghost]

Thankfully WordPress has core issues out to move to ESlint. They wouldn't bite on JavaScript Stamdard when I proposed it on Trac, citing technical debt and a desire to make JS look like their PHP as the rationale.