GitHub collaboration resources

[chris48s]

At the moment, the linting rules that JSHint is currently enforcing don't 'agree' with the code style guide linked.

As an example, JSHint is configured to require semicolons (this is the default for JSHint, but you can turn it off ), whereas the 'standard js' coding style says you should not use semicolons and rely on ASI.

As another example, JSHint currently requires strict comparisons in all situations (again, the default for JSHint) but the proposed conventions allow obj == null (again this is configurable ).

I'm aware that I set up the JSHint config (I mainly just went with the defaults), but I don't raise this because I want to start a big debate about semicolons. GitHub has enough of those already ;) Being an electron app, it is probably better to move into line with the electron community conventions - I just think that part of adopting style guidelines should be updating the existing codebase and linting rules (or tools ) to meet/enforce those guidelines.

[pezholio]

I think Standard.js would be a good shout for this 👍

[Stephen-Gates]

Standard.js seems perfect given the list of users includes Electron, NPM, GOV.UK and more.

[chris48s]

So I think the steps to adopting that should be:

• [ ] Add standard js to project requirements

• [ ] Bring existing code into line with guidance:

  • Run standard --fix on codebase to automatically convert as much as possible to to standard js conventions
  • Mop any issues that need manual intervention

• [ ] Remove JsHint config files (.jshintrc, .jshintignore) from root/subdirs + JsHint package

• [ ] Edit Travis config to run Standard Js linter in CI build instead of JsHint

[quadrophobiac]

Hey everyone - thanks so much for the input on this, really great discussion and especially thanks to you @chris48s for speccing out what should be done. I'll get those into tickets and into the backlog!