Define standard linting rules to automate style-related PR reviews

[adoptopenjdk]

Define standard linting rules to automate style-related PR reviews

[gdams]

fixed by #157

[ParkerM]

Some personal preferences in approximate descending order of severity:

• Prefer let/const over var:
  prevents scoped declarations affecting global state
• Prefer const when possible:
  changes to mutability must be explicitly addressed
• Spaces over tabs, \n for line breaks:
  (fish in a barrel)
• Force (or disallow) usage of semicolon where applicable:
  consistency is key
• Consistent lengths for indents and continuation:
  no opinion on what the length is, just ensure consistency
• Prefer trailing commas on multi-line arrays/objects:
  makes diffs much more readable for single-line additions
• Enforce trailing newlines:
  in the same vein, makes commits easier to work with
• Consistent usage of single or double quotes for simple string constants:
  possibly nitpicky but can be a big QoL improvement as a project grows. It's also fairly configurable (e.g. require single quotes unless string itself contains single quotes, handle special string-template cases, etc.)

Not to say that any of these are objectively worthy of death by CI, but a warning at the very least would improve usability and allow users to use their IDE's autoformatter without fear of introducing a thousand tiny changes.

[karianna]

Don't see why not - we have similar PR testing on other repos

[johnoliver]

Since we are looking at starting v3 from a blank slate. It is probable we will move to a JVM based tech/language for the api in the future.

[karianna]

Since we are looking at starting v3 from a blank slate. It is probable we will move to a JVM based tech/language for the api in the future.

Happy with that, as long as we have the same ease of deployment as the existing API on OpenShift

[ParkerM]

Since we are looking at starting v3 from a blank slate. It is probable we will move to a JVM based tech/language for the api in the future.

That'd be awesome! I suppose something like Checkstyle or ktlint could be useful in that case.