TOOLS: Add pre-commit hooks

[catloversg]

Note: This is an experimental PR. I'm not sure if we really need this one.

Ideally, when a contributor creates a PR, they should run all these steps:

• npm run format: Reformat code.
• npm run lint: Run ESLint to catch potential mistakes.
• npm run test: Run all test suites.
• npm run doc: Generate docs.

However, many contributors do not do them. Some don't know that they should do that. Some (including me) are lazy and just let the CI system catch the problems. Recently, a contributor asked us if npm run doc is in our workflow, and the answer is no. Setting pre-commit hooks may be useful, and it is also common practice in many projects, so I decide to test it.

Currently, the process of creating a PR is fairly "free-style". The contributor can ignore all those npm steps while drafting the PR. They only need to deal with them right before we review the PR. I think this is good; it's annoying to be forced to run many commands every commit, especially in the early stage of the PR. Therefore, in this PR, I only run prettier and npm run doc when necessary and only with staged files.

Note that even after running npm run doc, the contributor still has to manually stage some files (e.g., src/Documentation/pages.ts, md and images files in src/Documentation/). We can automatically stage them, but it may be annoying for the contributor if there are some files that they specifically don't want to commit (e.g., incomplete md files).

@d0sboots What do you think about this idea?

[d0sboots]

This could work, but I was originally thinking of an actual workflow action that operates on the PR itself. This has its own issues though; either modifying the PR on each push, or adding an additional step as part of the merge, or possibly a "check" step that merely checks that docs are up to date instead of altering the PR.

[catloversg]

I think adding a new "check" step is okay. Modifying the PR (as in committing/pushing) is very troublesome. In order to do that, the workflow must have the write permission to the PR branch, which is in the contributor's repository. I'm not sure if it's possible. I messed around with that idea before making this PR, but I have not found a good solution.

[d0sboots]

I think the 2nd option (modify as part of merge) would potentially only require write permission for the main repo, but I also think a new check (or possibly just structuring it as a test) would work best. We could also choose to ignore it for me committers, still.