Migrate from Standard to ESLint and Prettier

[alexwaibel]

This may be a controversial PR since it's related to style preferences, but I think it's worth making the jump from Standard for linting and formatting to ESLint for linting and Prettier for formatting for a few reasons:

• ESLint and Prettier are more widely used than Standard. See their npm package download numbers: eslint standard
• ESLint and Prettier integrate better with modern development tools (great VS Code extensions) than Standard
• ESLint is more flexible. For example, we could keep using it if we migrated to TypeScript.
• ESLint and Prettier can handle more file types and apply rules to things like json and yml files
• ESLint can enforce much more strict coding standards

Some of the new rules enforced:

• No unused variables
• Expect trailing commas
  • Ensuring we have trailing commas when possible means code diffs are less noisy. Adding a line does not require adding a comma to the previous line, because there was already a comma there.
• Expect semicolons
  • Makes it easier to identify the end of statements.
• Functions that don't use this must be static
• Variable names reused from parent scope
• Consistent returns
• Switch statements must have defaults
• Many more

I went ahead and drafted up this code, with all the linting passing. I think it's important to enforce a strict style for this project so we make sure the code is as consistent as we can make it. This cuts down on noise in PRs as the rules are already programmatically set in place and do not have to be discussed regularly. Please look through the PR code and let me know what you think.

I've also added husky and lint-staged. These automatically run the formatter and try to automatically fix any style errors whenever you commit files. This should stop build failures for style warnings from happening in PRs.

[eduardoboucas]

I'm all for adding Prettier. I think it's a great choice.

The only thing I'm personally not a big fan of is the introduction of semi-colons. They're pretty much useless, and Node itself doesn't use them.

It's easy to remove them from Prettier. Would you be open to doing that?

[alexwaibel]

The only thing I'm personally not a big fan of is the introduction of semi-colons. They're pretty much useless, and Node itself doesn't use them.

While it's true that the Node interpreter doesn't require semicolons, when they're omitted it uses Automatic Semicolon Insertion to insert the semicolons when not present. This can lead to unexpected behavior if the ASI misinterprets things like line breaks. Explicitly including semicolons helps avoid these issues. IMO it's better to be explicit in the codebase than to expect contributors to remember the edge cases of the ASI. You can read further justification in the Airbnb Style Guide.

While semicolons are not required by the interpreter, I generally find their presence makes code easier to skim through. With semicolons, it's very obvious where statements end and you get more informative errors about missing tokens in your editor. With prettier running automatically as a pre-commit hook, you don't even have to actually type semicolon characters. They'll be automatically inserted by the formatter when you commit.

It's easy to remove them from Prettier. Would you be open to doing that?

Sure, we could do this. It's easy enough to change the rule and rerun prettier to remove them all if you're unconvinced by the above.