Core JS is inconsistent and contains basic mistakes that are easily avoidable once we make people aware of them.
In order to keep our JS code consistent we should rely on a dedicated tool able to spot common and well known issues. Two exists for JS code: JSLint and JSHint. Both have the same capabilities with JSHint being more flexible and a better fit for us.
This issue is about deciding on which options the JS code should be checked with. It is going to be the basis on which our coding standards will live. JSHint can be used as a regular script, as a node js module and is integrated in a few IDEs. Using JSHint will make sure the JS shipped doesn't contain syntax errors or leaking variables, and will make sure the code can be minified properly.
This set of options has been agreed upon, it builds up from the configuration of the jQuery project adding a few Drupal-related rules:
"browser" : true,
"curly" : true,
"eqeqeq" : true,
"expr" : true,
"forin" : true,
"latedef" : true,
"newcap" : true,
"noarg" : true,
"trailing" : true,
"undef" : true,
"predef" : [
It will allow us to guard against various mistakes and enforce a consistent code.
- find the right place to put the configuration in. Coder? only attached to the coding standards page?
User interface changes
Once all the core JS files are fixed, each patch should be run — manually — through JSHint to check coding standards are respected and that no new mistake that can be checked for are introduced by the patch.
Original report by Rob Loach
PASSED: [[SimpleTest]]: [MySQL] 54,170 pass(es).
PASSED: [[SimpleTest]]: [MySQL] 53,860 pass(es).
PASSED: [[SimpleTest]]: [MySQL] 53,994 pass(es).
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch core-jshint-config-1664940-99.patch. Unable to apply patch. See the log in the details link for more information.