chore: add lint autofix CI job

[slorber]

Motivation

It is very time-consuming in the long run to fix lint issues in internal/external PRs

This job should do it automatically by commiting to the PRs to fix

Regarding spelling, it is even more painful to manage the project-words.txt list manually, so let's move to a simpler workflow where we don't manage that list ourselves, but only review the generated one in PRs: after all we want to be noticed when an unknown word is introduced, and this can be done by reviewing an automated addition to the project-words.txt file.

Test Plan

CI

[netlify]

✅ [V2]

Name	Link
🔨 Latest commit	3ede3fb
🔍 Latest deploy log	https://app.netlify.com/sites/docusaurus-2/deploys/656a20944956de0008f7a489
😎 Deploy Preview	https://deploy-preview-9604--docusaurus-2.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[github-actions]

⚡️ Lighthouse report for the deploy preview of this PR

URL	Performance	Accessibility	Best Practices	SEO	PWA	Report
/	🟠 74	🟢 98	🟢 100	🟢 100	🟠 89	Report
/docs/installation	🟠 66	🟢 98	🟢 100	🟢 100	🟠 89	Report
/docs/category/getting-started	🟠 76	🟢 100	🟢 100	🟢 90	🟠 89	Report
/blog	🟠 75	🟢 100	🟢 100	🟢 90	🟠 89	Report
/blog/preparing-your-site-for-docusaurus-v3	🟠 64	🟢 97	🟢 100	🟢 100	🟠 89	Report
/blog/tags/release	🟠 76	🟢 100	🟢 100	🟠 80	🟠 89	Report
/blog/tags	🟠 76	🟢 100	🟢 100	🟢 90	🟠 89	Report

[netlify]

✅ [V2]

Name	Link
🔨 Latest commit	c08f4c9
🔍 Latest deploy log	https://app.netlify.com/sites/docusaurus-2/deploys/656a219c9412c50008639104
😎 Deploy Preview	https://deploy-preview-9604--docusaurus-2.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[github-actions]

Size Change: 0 B

Total Size: 926 kB

ℹ️ View Unchanged

Filename	Size
website/.docusaurus/globalData.json	58.9 kB
website/build/assets/css/styles.********.css	114 kB
website/build/assets/js/main.********.js	715 kB
website/build/index.html	37.6 kB

_{compressed-size-action}

[Josh-Cena]

We should not "autofix" spelling. This is not safe and hard to review. For example, words with different capitalization will now show up as separate entries.

[Josh-Cena]

I can see the point of auto-applying linting/prettier fixes (although I don't find it too painful), but auto-fixing spelling seems too risky.

it is even more painful to manage the project-words.txt list manually

Is it? For me personally: I use my editor to transform everything to lowercase and then sort it alphabetically. I'm aware that alphabetical order may be locale-dependent, but can we simply have a script that does this using Intl.Collator("en-US") to iron out the discrepancies?

[slorber]

I can see the point of auto-applying linting/prettier fixes (although I don't find it too painful)

I spend a lot of time fixing patch-x PRs of external contributors, particularly for docs. This is a real pain for me to not being able to merge half of good-enough docs PRs immediately.

#9490

https://github.com/facebook/docusaurus/actions/runs/6721876263/job/18268564837?pr=9490

Prettier/CI doesn't even tell you the problem:

So I have to load it locally and fix it every time.

And then need to wait for the CI to complete again before merging, which keeps my brain busy and context switch again for no good reason.

---

Regarding project-words.txt, similarly external contributors are not aware of it, it's basically impossible to find what to fix for someone unaware, and I have to also do this workflow.

We should not "autofix" spelling. This is not safe and hard to review. For example, words with different capitalization will now show up as separate entries.

The goal is not to autofix spelling but to be aware when there's an unknown word.

I review all PRs carefully, including this file, and don't see how it's less safe than having an external contributor adding it by themselves: we don't care if it's someone else or CI that modifies the file, we always already have to review it.

The point is to be "aware" that something is happening here, and any diff to that file is enough for me.

The order, case sensitiveness, deduplication doesn't matter much to me as long as I can review a diff. Actually I want to be aware when see "webpack" and "Webpack", that means we have an inconsistent usage of that lib name.

---

Not even counting the time lost due to using precommit hooks.
After years of using them, I kind of agree with this take and would rather remove them all:
https://www.youtube.com/watch?v=RAelLqnnOp0

---

So, for now I'll merge this and we'll see how it goes in practice. Happy to revisit but I'm confident it will be way better than it used to be.