docs: configure spell-check

.github/workflows/docs.yml

@@ -13,3 +13,4 @@ jobs:
     uses: FuelLabs/github-actions/.github/workflows/mdbook-docs.yml@master
     with:
       docs-src-path: 'docs/src'
+      spellcheck-config-path: 'docs/.spellcheck.yml'

docs/.spellcheck.yml

@@ -0,0 +1,29 @@
+matrix:
+    - name: SPCheck
+      aspell:
+        lang: en
+      dictionary:
+        encoding: utf-8
+        wordlists:
+          - docs/spell-check-custom-words.txt
+      pipeline:
+        - pyspelling.filters.context:
+            context_visible_first: true
+            escapes: \\[\\`~]
+            delimiters:
+            # Ignore all code blocks
+            - open: '(?s)^(?P<open> *`{3,}\s*(\w+\s*,?\s*)+.*?)$'
+              close: '^( *`{3,})$'
+        - pyspelling.filters.markdown:
+            markdown_extensions:
+              - pymdownx.superfences:
+        - pyspelling.filters.html:
+            comments: false
+            ignores:
+              - code
+              - pre
+      sources:
+        - 'docs/src/*.md'
+        - 'docs/src/**/*.md'
+      default_encoding: utf-8
+

docs/spell-check-custom-words.txt

@@ -0,0 +1,230 @@
+ABI
+ABIs
+ASM
+IDE
+IDEs
+LSP
+namespace
+ALU
+APIs
+JSON
+BrowserStack
+CLI
+Deserialization
+deserializing
+DApp
+subcurrency
+Subcurrency
+intrinsics
+Intrinsics
+workspace
+workspaces
+Workspaces
+neovim
+EVM
+EVM's
+EOA
+ERC
+Ethereum
+Ethereum's
+FVM
+FuelVM
+Fuelup
+Github
+GraphQL
+Infura
+JSON
+LSP
+Merkle
+PoA
+PoS
+PoW
+RPC
+SDK
+SDK's
+SDKs
+SauceLabs
+Sepolia
+Structs
+Sway
+TAI
+TODO
+TypeScript
+UTF
+UTXO
+UTXOs
+Utils
+VM
+VSCode
+abigen
+args
+async
+backend
+backtraces
+blockchain
+blockchain's
+bytecode
+codespace
+codespaces
+config
+cryptographic
+customizable
+customizations
+dapp
+dev
+dropdown
+enum
+enums
+env
+forc
+frontend
+fuelup
+fullstack
+graphQL
+graphql
+http
+https
+js
+localhost
+mainnet
+mempool
+merkle
+monorepo
+monorepos
+natively
+npm
+nvm
+onboarding
+params
+pnpm
+prerelease
+queryable
+quickstart
+relayer
+relayers
+repo
+repos
+runnable
+stateful
+struct
+structs
+struct's
+testnet
+testnets
+toolchain
+toolchains
+urql
+validator
+validators
+superABI
+superABIs
+SuperABIs
+supertraits
+compositional
+typeclass
+turbofish
+DSL
+TOML
+IPFS
+Bitwise
+Bitwise
+runtime
+runtimes
+formatter
+deployable
+Utils
+ETH
+initializer
+initializers
+destructuring
+instantiation
+VMs
+superset
+CEI
+pre
+entrancy
+interoperable
+blockchains
+keccak
+SHA
+UI
+backtrace
+Collateralized
+collateralized
+submodule
+DEX
+TypeChain
+inlines
+inlining
+MiB
+FuelVM's
+deterministically
+CLI
+VS
+GraphViz
+DOT
+DCA
+AST
+GitHub
+decrypt
+subcommand
+subcommands
+Subcommands
+supertrait
+supertraits
+Supertraits
+incrementor
+monomorphization
+Booleans
+boolean
+Orchestrator
+orchestrator
+growable
+arity
+tuple's
+unary
+SRC
+DEX
+FuelLabs
+PRs
+codebase
+PostgreSQL
+Postgres
+MacOS
+macOS
+backends
+hoc
+semver
+SQLx
+Homebrew
+Changelog
+lookups
+namespaces
+YAML
+WASM
+WebAssembly
+dApp
+dApps
+JWT
+Schemas
+schemas
+AssemblyScript
+indexable
+Macbook
+Dockerized
+TLDR
+IaaS
+Updatable
+SemVer
+executables
+unarchive
+reproducibility
+PowerShell
+ZSH
+Zsh
+distributable
+symlinks
+installable
+modularly
+changelog
+Fuelup's

docs/src/concepts/channels.md

@@ -30,7 +30,7 @@ The `nightly` channel is a published TOML file describing successful builds of t
 These builds are released in the [sway-nightly-binaries] repository and the workflows in that repo start building them every day at **00:00 UTC**.
 
 The `nightly` channel within `fuelup` is updated by a scheduled GitHub workflow that **runs every day at 01:00 UTC**, after builds have finished.
-Note that nightlies might fail to build, in which case it is possible that the `nightly` toolchain may not be available for that day.
+Note that the `nightly` channel might fail to build, in which case it is possible that the `nightly` toolchain may not be available for that day.
 
 You should use `nightly` if you want the latest changes to `master` that have not been officially released yet.
 Keep in mind that compatibility between `forc` and `fuel-core` is not guaranteed here, and you should expect unstable features to break.
@@ -55,19 +55,19 @@ The `latest` channel is pointing to our latest beta network. This toolchain shou
 >
 > Reading the information below is only really necessary if you wish to contribute to the workflows or want a deeper understanding on how channels are updated.
 
-The entrypoint of the scheduled workflow is within `index-versions.yml`. We run the Rust script `compare-versions` to collect versions of `forc` and `fuel-core` to be tested. These versions are filtered for incompatible versions prior to being used as a JSON string input to `test-toolchain-compatibility.yml`, where the testing occurs.
+The entry point of the scheduled workflow is within `index-versions.yml`. We run the Rust script `compare-versions` to collect versions of `forc` and `fuel-core` to be tested. These versions are filtered for incompatible versions prior to being used as a JSON string input to `test-toolchain-compatibility.yml`, where the testing occurs.
 
-In `test-toolchain-compatibility.yml`, The versions JSON string input is used to init a matrix using the [fromJSON](https://docs.github.com/en/actions/learn-github-actions/expressions#fromjson) expression. We checkout the Sway repo at the given `forc` version and pull the `fuel-core` Docker image at the given `fuel-core` version and run integration tests found in the [Sway CI](https://github.com/FuelLabs/sway/blob/3bd8eaf4a0f11a3009c9421100cc06c2e897b6c2/.github/workflows/ci.yml#L229-L270) for them.
+In `test-toolchain-compatibility.yml`, The versions JSON string input is used to initialize a matrix using the [`fromJSON`](https://docs.github.com/en/actions/learn-github-actions/expressions#fromjson) expression. We checkout the Sway repo at the given `forc` version and pull the `fuel-core` Docker image at the given `fuel-core` version and run integration tests found in the [Sway CI](https://github.com/FuelLabs/sway/blob/3bd8eaf4a0f11a3009c9421100cc06c2e897b6c2/.github/workflows/ci.yml#L229-L270) for them.
 
-Note that we only mark versions as incompatible specifically if tests fail, and not if other prior steps fail (eg. we do not want to mark versions as incompatible if there were errors pulling the Docker image)
+Note that we only mark versions as incompatible specifically if tests fail, and not if other prior steps fail (e.g. we do not want to mark versions as incompatible if there were errors pulling the Docker image)
 
 The [upload-artifact](https://github.com/actions/upload-artifact) action is used to collect the test results from the matrix to be used later in a [download-artifact](https://github.com/actions/download-artifact) step.
 
 If tests were not skipped and are now done, we finally get to the `index-versions` job. We download the artifacts that were previously uploaded to be used here. This job will:
 
-1. upload incompatible versions to gh-pages. These incompatible versions are named in the format `incompatible-forc-<FORC_VERSION>@fuel-core-<FUEL_CORE_VERSION>`.
+1. upload incompatible versions to `gh-pages`. These incompatible versions are named in the format `incompatible-forc-<FORC_VERSION>@fuel-core-<FUEL_CORE_VERSION>`.
 
-2. update the channel by filtering for the latest versions of `forc` and `fuel-core` that passed tests within the matrix by running `index-versions.sh`. These are named in the format `compatible-forc-<FORC_VERSION>@fuel-core-<FUEL_CORE_VERSION>`. Note that these files are not saved or uploaded onto gh-pages - they are only a way for the `test-toolchain-compatibility` job to share test results with this job.
+2. update the channel by filtering for the latest versions of `forc` and `fuel-core` that passed tests within the matrix by running `index-versions.sh`. These are named in the format `compatible-forc-<FORC_VERSION>@fuel-core-<FUEL_CORE_VERSION>`. Note that these files are not saved or uploaded onto `gh-pages` - they are only a way for the `test-toolchain-compatibility` job to share test results with this job.
 
 ### Debugging the workflow
 
@@ -79,7 +79,7 @@ Some changes you might want to make to allow for easier testing:
 
 2. You can also exit with 0 or 1 in jobs or steps where you want it to pass/fail.
 
-You may also use [nektos/act](https://github.com/nektos/act) to run the workflow(s) locally.
+You may also use [`nektos/act`](https://github.com/nektos/act) to run the workflow(s) locally.
 
 [sway-nightly-binaries]: https://github.com/FuelLabs/sway-nightly-binaries/releases
 [latest]: #the-latest-channel

docs/src/concepts/how_fuelup_works.md

@@ -8,7 +8,7 @@ toolchains and presents them all through a single set of tools within `~/.fuelup
 
 Generally, it is not recommended to manually make changes to the fuelup directory, otherwise `fuelup`
 might not function as expected. If you have made changes to the directory, we recommend removing
-the entire directory and re-installing fuelup with [fuelup-init].
+the entire directory and re-installing fuelup with [`fuelup-init`].
 
 ## Proxies
 
@@ -39,7 +39,7 @@ turn executes the correct version of `forc` based on either an override file (`f
 or your currently active toolchain (in order of priority).
 <!-- fuelup_example:example:end -->
 
-[fuelup-init]: ../installation/index.md#quickstart
+[`fuelup-init`]: ../installation/index.md#quickstart
 [`rustup`]: https://github.com/rust-lang/rustup
 [`forc`]: https://fuellabs.github.io/sway/master/book/forc/index.html
 [`fuel-core`]: https://github.com/FuelLabs/fuel-core

docs/src/concepts/toolchains.md

@@ -5,7 +5,7 @@
 Many `fuelup` commands deal with _toolchains_, a single installation of the
 Fuel toolchain. `fuelup` supports **two** types of toolchains.
 
-1. Distributable toolchains which track the official release [channels] (eg, _latest_, _nightly_);
+1. Distributable toolchains which track the official release [channels] (e.g., _latest_, _nightly_);
 2. Custom toolchains and install individual components in a modular manner.
 <!-- toolchains:example:end -->
 
@@ -36,7 +36,7 @@ For most use cases, using the officially packaged toolchains is good enough.
 For advanced use cases, `fuelup` allows you to build a toolchain in a
 modular manner, and to specify specific versions of components to install.
 
-To init a new, empty toolchain:
+To initialize a new, empty toolchain:
 
 ```sh
 fuelup toolchain new my_toolchain

docs/src/configuration.md

@@ -69,9 +69,9 @@ Now you can install the completions script using the following command:
 fuelup completions --shell=zsh > ~/.zfunc/_fuelup
 ```
 
-### POWERSHELL
+### PowerShell
 
-The powershell completion scripts require PowerShell v5.0+ (which comes with Windows 10, but can be
+The `powershell` completion scripts require PowerShell v5.0+ (which comes with Windows 10, but can be
 downloaded separately for windows 7 or 8.1).
 
 First, check if a profile has already been set

docs/src/developer_guide/adding_components.md

@@ -3,7 +3,7 @@
 Adding components in `fuelup` is often just a small PR to [`components.toml`] in the repo, followed by a
 new release of `fuelup`.
 
-## Contributing to components.toml
+## Contributing to `components.toml`
 
 This section describes how you may add support for a binary within `fuelup`.