docs: configure spell-check

[sarahschwartz]

This PR configures the spell-check added to the docs workflow in the github-actions repo: FuelLabs/github-actions#23

The files checked are configured in .spellcheck.yml. This is also where you can configure what types of elements are ignored.

Right now it ignores:

• All code blocks that have a language (and will check code blocks that do not have a language)
• Anything in between backticks
• Words in spell-check-custom-words.txt (case sensitive, only exact match)
• Numbers, even if they are attached to a word
• Links in markdown link format

Handling errors:

If the test fails:

• look up the word in the question to verify it is a real word and is correctly spelled
• If it is a file name or is code, use backticks to ignore the word.
• If it is a real word that is spelled correctly, or an acronym that is either common or is defined already, add it to spell-check-custom-words.txt.
• If needed, rewrite the sentence. Ex: DON'T use "locking" and add "ing" to the custom words list. Instead, rewrite the sentence as "locking with the lock method".
• If it otherwise should be ignored, you can configure the pipeline in .spellcheck.yml.

[github-actions]

Coverage report for ./packages/app

St.❔	Category	Percentage	Covered / Total
🟡	Statements	66.58%	3381/5078
🔴	Branches	43.93%	619/1409
🔴	Functions	50.21%	713/1420
🟡	Lines	67.2%	3260/4851

Test suite run success

241 tests passing in 73 suites.

Report generated by 🧪jest coverage report action from 297230e

[LuizAsFight]

great work here !

@sarahschwartz can the list of words be in the CI itself inside of in this project ? then it can be easily reused across other projects

[LuizAsFight]

also maybe this PR can wait for other PRs as RN we have going the

• updates to beta-5
• fixes on intermittent tests

after that will be ready to merge

[sarahschwartz]

It can wait as long as you don't make any other changes to the docs, since the docs workflow is broken without this.

And I thought about keeping the custom words list in one place, but I'm afraid that would slow down development since you would have to update 2 repos. Most tech terms need to be added to the list.

[luizstacio]

It can wait as long as you don't make any other changes to the docs, since the docs workflow is broken without this.

And I thought about keeping the custom words list in one place, but I'm afraid that would slow down development since you would have to update 2 repos. Most tech terms need to be added to the list.

We could have a default list and allow a per repo bases list also. In this way we would make the CI simpler, and if we need to customize it would be fast.

[sarahschwartz]

We could have a default list and allow a per repo bases list also. In this way we would make the CI simpler, and if we need to customize it would be fast.

That could work, I will follow up with another PR to do this later if that's ok.