Clean up linting configuration

[edmorley]

• Switch back from babel-eslint to the default ESLint parser, since it supports all of the syntax we are using out of the box.
• Use the new ignorePatterns option instead of .eslintignore.
• Adjust the ignore pattern from !.eslintrc.js to !.*.js so that all dotfiles are un-ignored, which also allows us to remove the multiple globbing combinations in the ESLint CLI command used for yarn lint, and instead pass just ..
• Use the new reportUnusedDisableDirectives option instead of the --report-unused-disable-directives CLI flag.
• Enable --max-warnings 0 so that CI fails for warnings too.
• Move the Prettier config out of .eslintrc.js to .prettierrc.js, since not all editor integrations check the ESLint config location.
• Switch from running Prettier as an ESLint plugin to using the native CLI, since it's faster, the UX is better when using editor integrations (eg prevents lots of red underlines which will be fixed on save anyway), and it means non-JS file types can be formatted. Additional package.json scripts have been added to make it easier for those who don't use format-on-save to apply fixes.
• The previously unchecked files (*.json and files under types/) have had their formatting fixed using yarn fix.

[eliperelman]

LGTM! The one thing I am concerned about is moving away from babel-eslint, as it will make the switch back to it a little less fun, but I think it's probably the right choice. Nevermind, was looking at the wrong repo. 😄

[edmorley]

Re the switch away from babel-eslint, my thoughts were that if we end up using non-standard syntax, we'll have to use add a build step for transpiling that (particularly given webpack-chain supports more Node versions than say Neutrino) - and so (a) it might mean we're less inclined to do that, (b) even if we do, we'll require a bunch of changes to add the build step, and we can switch back to babel-eslint at that point :-)