Kicking off a discussion. As a general rule style guidelines should all be automated so that code reviews don't get bogged down by discussion of whitespace preferences.

• Use prettier for code formatting.
  • Everyone should enable "format-on-save"
  • We should check formatting as part of CI
  • Single quotes, two character indent, yes to semicolons, 80 character width (some groups prefer 100)
• Use a recent version of TypeScript with strict set
• Use eslint for linting
  • Enable eslint:recommended
  • Enable [`@typescript-eslint/recommended'](eslint:recommended', 'plugin:@typescript-eslint/recommended)
  • Enable plugin:react/recommended and plugin:react-hooks/recommended

Some other suggestions of mine, open to discussion.

General JavaScript:

• Avoid export default (named exports encourage consistent use of the same name for the same thing).
• Use a canonical ordering for imports with three (or fewer) groups separated by a blank line, alphabetized within each group (this can be automated with the simple-import-sort eslint plugin):

  import {foo} from 'node-module1';
  import {bar} from 'node-module2';
  
  import {baz} from './relative-import/a';
  import {quux} from './relative-import/b';
  
  import './static-asset.css';

• Use async / await instead of raw Promises and .then whenever possible.

A few TypeScript-specific rules:

• Avoid any wherever reasonably possible.
• Prefer interface to type where possible for simple object types (your type will show up more predictably in error messages and it will improve TypeScript compiler performance for large code bases).
• Prefer T[] to Array<T> unless T is very complex and the latter reads more clearly.
• Avoid non-standard TypeScript language extensions such as enum and parameter properties
• Use synthetic default imports where possible, e.g. import React from 'react'; instead of import * as React from 'react';

@cguedes @sergioramos @sehyod would love feedback and suggestions!