Moving fully to eslint, removing prettier

[filmaj]

🙌 All of these changes are courtesy of @aoberoi and the work they put into #669 🙇

Summary

This PR is the beginning of a journey to tackle #842. The goals are:

• 😌 when in doubt, formalize the existing style in the project, in order to avoid overchoice (being overwhelmed with too many options)
• 🔪 remove prettier
• 🥗 use a single eslint configuration for both project and test code
• 👪 get buy-in from the team / project maintainers on the core testing / linting tools and configurations that we use on a daily basis to make our work more enjoyable and productive

This pull request fixes #842

Progress

Using this PR and running npm run lint currently yields:

✖ 189 problems (189 warnings)

🤓 Process

Tackling #842 is a big task! It will require many changes to many files across the project. As such, I propose we employ a divide-and-conquer approach consisting of many pull requests that would look something like the below. This is only a suggestion and I welcome feedback on the approach and am open to other alternatives!

• First, we can review and discuss just the configuration changes on their own - just the changes encapsulated in this initial pull request. Are some linting and/or compilation rules silly, unwieldy or we just plain don't like them? Are there some favourite linting rules that we are missing that you believe we should include? This initial configuration review is rather "abstract" in the sense that it is divorced from seeing the impact of the configuration changes in project source code. However, that comes next!
• Next, we can issue additional pull requests, using this tslint-to-eslint branch as a base, to offer suggestions on how to change the configurations / linting rules. These config/lint rule change PRs may be accompanied with the appropriate source code changes enabling project source to pass the rules in question. I think this offers an experimental and "let's try it out and see!" approach to figuring out which linting rules we want to include and which ones we want to move away from. With each such micro-PR merged into this PR, this base PR should in theory come closer and closer to passing the CI, as each PR should remove some number of linting errors.
• Finally, once one or more micro-PRs have been merged into this PR and the CI passes, we can merge this PR into main.

📝 TODO

Just keeping a running track of outstanding tasks here - this section will likely be edited many times as this PR is worked on.

• Fix the package.json linting run scripts - in particular there is still a run script for linting test source. Perhaps this extra run script can be removed if we complete combining the source-and-test eslint configurations into one file?
• ESLint Config Migration: Add a src/types-specific rule #1025: Update the type property naming conventions for source files under src/types/**/*.ts
• ESLint Config Migration: Fix import/order lint rules failing #1031: Fix ordering of imports
• [WIP] ESLint Config Migration: Expand import/no-internal-modules allowlist #1032: Allow certain source directories to be "reached into" when importing from (addresses import/no-internal-modules errors)
• ESLint Config Migration: Fix indentation linter warnings #1033: Fix indentation linter errors
• ESLint Config Migration: Fixing lint errors for "no-use-before-define" rule. #1036: Fix lint errors for the no-use-before-define rule
• ESLint Config Migration: Tweak the operator-linebreak lint rule #1037: Tweak the operator-linebreak rule
• ESLint Config Migration: Remove no-inferrable-types rule #1041: Remove the no-inferrable-types rule
• ESLint Config Migration: Fix missing function return types #1042: Fix missing function return types
• ESLint Config Migration: Export a function by default in modules #1043: Fix prefer-default-export rule
• ESLint Config Migration: Add test-specific ruleset #1044: Add test-specific ruleset
• ESLint Config Migration: Allow unused vars with leading underscores #1045: Allow leading underscores for variables to signify they should be ignored
• Choice of:
  • ESLint Config Migration: Turn off consistent-return from linting rules #1049: Turn off consistent-return rule
  • ESLint Config Migration: Fixing consistent-return linter warnings #1075: Fix code to follow consistent-return rule.
• ESLint Config Migration: Remove strict-boolean-expressions rule #1050: Turn off strict-boolean-expressions rule
• ESLint Config Migration: Object property names enclosed with quotes require no naming convention #1051: Allow for object properties to be named anything as long as you quote them
• ESLint Config Migration: Enum members should use PascalCase #1052: Enum Member should be PascalCase
• ESLint Config Migration: Use tsconfig's resolveJsonModule, replace require with import #1053: Replace require with import, allow use of import for JSON files
• ESLint Config Migration: Disable max-classes-per-file rule #1054: Disable max-classes-per-file rule
• ESLint Config Migration: Disable the only occurrences of no-nested-ternary rule violation #1055: Disable occurrences of no-nested-ternary - but maybe rewrite this section of the code?
• Go through code, searching for eslint- and tslint: comments/directives and update accordingly based on new config
• Double-check the dependencies (especially the new additions). Are they still needed?

Requirements (place an x in each [ ])

• I've read and understood the Contributing Guidelines and have done my best effort to follow them.
• I've read and agree to the Code of Conduct.

[filmaj]

I've created on such micro-PR, addressing the naming convention of type properties for source code located under src/types here: #1025. I hope this is helpful to demonstrate the kind of process/approach I suggested in tackling this task. Let me know what you all think!

EDIT: This has now been merged in.

[filmaj]

I have and will be issuing several more pull requests (I list them all in under the TODO section of the original post in this PR). I am trying to group the PRs by rule - one PR per rule, basically. I have merged the ones that do not change any existing rules and just adhere to relatively common / well-accepted rules already - but that does not mean those cannot be easily reverted or modified. I have also left the PRs that change lint rules open for review for people. In either case: all open/closed/merged PRs listed under the TODO section can be reviewed at the team's leisure, and comments can be left there.

Once I have created PRs for all rules that are failing, I will comment again.

[filmaj]

Alright, with @srajiang resolving the update to TS issues, I have now rebased this PR with the latest main. Let's see what shakes out from CI!

EDIT: FYI we will get this warning for now I suppose? Linting and tests still pass fine regardless.

WARNING: You are currently running a version of TypeScript which is not officially supported by @typescript-eslint/typescript-estree.

You may find that it works just fine, or you may not.

SUPPORTED TYPESCRIPT VERSIONS: >=3.3.1 <4.4.0

YOUR TYPESCRIPT VERSION: 4.4.2

Please only submit bug reports when using the officially supported version.