ci: add prettier (#11)

ci: add prettier

Author: KaiserKarel

ARCHITECTURE.md

@@ -4,7 +4,7 @@ This document describes the high-level architecture of Union and associated pack
 
 ## Repository Structure
 
-At the root of the repository, you'll find directories such as `uniond`, `unionvisor`, and `unionpd`, which are binaries necessary to run the network. To see how to build one of these binaries, check the `flake.nix` file. These binaries can be built by running 
+At the root of the repository, you'll find directories such as `uniond`, `unionvisor`, and `unionpd`, which are binaries necessary to run the network. To see how to build one of these binaries, check the `flake.nix` file. These binaries can be built by running
 
 ```nix
 nix build .\#uniond # or unionvisor or unionpd
@@ -14,15 +14,15 @@ To see all packages/apps that we define, run `nix flake show`. To see how these
 
 ### Generated Code
 
-Currently generated code, such as protobuf definitions and a vendor directory, are checked into the repo. This will be removed later once we add support for private repos and proto derivations. 
+Currently generated code, such as protobuf definitions and a vendor directory, are checked into the repo. This will be removed later once we add support for private repos and proto derivations.
 
 ### READMEs
 
-We attempt to have a README.md for every significant component, describing what it is and how to work on it. 
+We attempt to have a README.md for every significant component, describing what it is and how to work on it.
 
 ### Documentation
 
-Source code is always the source of truth. The best location to get into the nitty-gritty details is doc comments. We currently do not publish these, but might in the future. 
+Source code is always the source of truth. The best location to get into the nitty-gritty details is doc comments. We currently do not publish these, but might in the future.
 
 We refrain from separating docs and links from the actual code, as refactors can create dead links and stale docs. It's best to use text search to find where components are defined, as PRs are still adding significant components.
 
@@ -34,7 +34,7 @@ We refrain from separating docs and links from the actual code, as refactors can
 `unionvisor` is a supervisor of `uniond`, which makes deployments easier and more resilient. It is not required for node operations but is recommended.
 `unionpd` is the ZK prover. Validators do not need to run it, but IBC relayers and MEV searchers will need to process transactions and capture value.
 
-### Support 
+### Support
 
-`tools` is used to bring in 3rd party tooling and development tools. 
+`tools` is used to bring in 3rd party tooling and development tools.
 `networks` is used to define docker-compose configurations of Union and Ethereum networks for local testing.

CONTRIBUTING.md

@@ -1,6 +1,6 @@
 # Welcome to Union
 
-Thank you for investing your time in contributing to our project! 
+Thank you for investing your time in contributing to our project!
 
 In this guide, you will get an overview of the contribution workflow from opening an issue, creating a PR, reviewing, and merging the PR.
 
@@ -16,7 +16,6 @@ We evaluate the need for a PR based on:
 2. Maintainability: will this become a burden for little gain, or add value?
 3. Can the core team understand the code additions being made, and maintain them, or will they rely on you in the future?
 
-
 ## Working on a PR
 
 Make sure to check the ARCHITECTURE.md document to get a feel for the repository structure. It explains our build system more in-depth. If you want to run approximately the same tests as CI does, run `nix flake check`. For this, you will need to install [nix](https://zero-to-nix.com/start/install).
@@ -25,7 +24,7 @@ Make sure to check the ARCHITECTURE.md document to get a feel for the repository
 
 Sometimes you might need to extend the CI. For this always use nix. You'll need to keep a few things into account:
 
-1. Your additions must ensure compatibility with our supported targets: 
+1. Your additions must ensure compatibility with our supported targets:
 
 ```nix
 systems = [ "x86_64-linux" "aarch64-linux" "aarch64-darwin" "x86_64-darwin" ];
@@ -49,5 +48,4 @@ Finally, remain polite and friendly. Reviewing can feel harsh, but it is a learn
 
 ## Post-Merge
 
-You'll be an official contributor and mentioned in the release, as well as visible in GitHub's analytics. 
-
+You'll be an official contributor and mentioned in the release, as well as visible in GitHub's analytics.

VERSIONING.md

@@ -8,15 +8,15 @@ Two main versioning processes are elaborated on below: our use of semantic versi
 
 Our implementation of semantic versioning is in the form of `v{X}.{Y}.{Z}` where:
 
-* `{X}` indicates the major version. Major versions contain new features that may be incompatible with older versions and alter union's consensus. Detailed release notes and announcements can be expected for major versions.
+- `{X}` indicates the major version. Major versions contain new features that may be incompatible with older versions and alter union's consensus. Detailed release notes and announcements can be expected for major versions.
 
   Node Update: `required`
 
-* `{Y}` indicates the minor version. Minor versions may contain non-feature changes that may still be breaking. Usually these are reserved for security updates and bug fixes. Detailed release notes and announcements can be expected for minor versions.
+- `{Y}` indicates the minor version. Minor versions may contain non-feature changes that may still be breaking. Usually these are reserved for security updates and bug fixes. Detailed release notes and announcements can be expected for minor versions.
 
   Node Update: `required`
 
-* `{Z}` indicates the patch version. Patch versions will not contain breaking changes or new features. Release notes will be auto-generated from git commits for patch versions, announcements should not be expected.
+- `{Z}` indicates the patch version. Patch versions will not contain breaking changes or new features. Release notes will be auto-generated from git commits for patch versions, announcements should not be expected.
 
   Node Update: `optional`
 

cspell.json

@@ -8,13 +8,7 @@
       "addWords": true
     }
   ],
-  "dictionaries": [
-    "en_US",
-    "companies",
-    "softwareTerms",
-    "go",
-    "union"
-  ],
+  "dictionaries": ["en_US", "companies", "softwareTerms", "go", "union"],
   "ignorePaths": [
     "rust/ethereum-light-client/src/test/valid_light_client_update_*.json",
     "rust/protos/*",

docs/README.md

@@ -10,10 +10,8 @@ nix run .\#docs-dev-server
 
 Then open [localhost:3000](http://localhost:3000) in your browser. Edit the contents of `docs/` and see them change live in your browser.
 
-
 ## Static Build
 
 ```
 nix build .\#docs
 ```
-

docs/babel.config.js

@@ -1,3 +1,3 @@
 module.exports = {
-  presets: [require.resolve('@docusaurus/core/lib/babel/preset')],
+  presets: [require.resolve("@docusaurus/core/lib/babel/preset")],
 };

docs/docs/architecture/mainnet.md

@@ -1,12 +1,12 @@
 ---
-title: 'Mainnet Overview'
+title: "Mainnet Overview"
 ---
 
 # Mainnet
 
-The union.fi mainnet release date will be announced after the public testnet period has ended. 
+The union.fi mainnet release date will be announced after the public testnet period has ended.
 
-## Genesis 
+## Genesis
 
 The network will be bootstrapped with the top validators from the public testnet
 
@@ -20,4 +20,4 @@ The network has an initial active validator set size of 64, which may be increas
 
 ### Prover
 
-The prover connects over the RPC interface to construct CometBLS-Groth16 proofs. It submits these to the Ethereum.
+The prover connects over the RPC interface to construct CometBLS-Groth16 proofs. It submits these to the Ethereum.

docs/docs/architecture/testnet.md

@@ -1,25 +1,25 @@
 ---
-title: 'Testnet Overview'
+title: "Testnet Overview"
 ---
 
 # Testnet
 
-The union.fi testnet acts as a production-like staging environment, tracking the release candidates of [uniond](https://github.com/unionfi/union). 
+The union.fi testnet acts as a production-like staging environment, tracking the release candidates of [uniond](https://github.com/unionfi/union).
 
-## Genesis 
+## Genesis
 
 The network was bootstrapped with 6 validators from the founding team. The genesis config may be found [here](https://github.com/UnionFi/genesis).
 
 ## Architecture
 
 ### Topology
 
-The private testnet has 6 validators. It is not configured to be proof of authority (POA), but since tokens are not available until the public testnet, it is effectively a POA chain. The genesis validators are used as boot and RPC nodes. 
+The private testnet has 6 validators. It is not configured to be proof of authority (POA), but since tokens are not available until the public testnet, it is effectively a POA chain. The genesis validators are used as boot and RPC nodes.
 
 <img src="/img/testnet-overview.drawio.svg"  width="100%" height="30%"/>
 
 ### Prover
 
 The prover connects over the RPC interface to construct CometBLS-Groth16 proofs. It submits these to the [Goerli Testnet](https://goerli.net/).
 
-In production configurations, a relayer should connect to its validator to avoid data withholding attacks and for increased reliability.
+In production configurations, a relayer should connect to its validator to avoid data withholding attacks and for increased reliability.

docs/docs/intro.md

@@ -4,4 +4,4 @@ slug: /
 
 # Union Finance
 
-Union Finance docs.
+Union Finance docs.

docs/docs/nodes-validators/create-testnet-genesis.md

@@ -1,5 +1,5 @@
 ---
-title: 'Creating the Testnet Genesis'
+title: "Creating the Testnet Genesis"
 ---
 
 <!--
@@ -23,7 +23,7 @@ Both the host node and genesis validators should generate an app key pair.
 
 To add your app key, you can use the `uniond keys` interface to either create a new key pair or import an existing key pair.
 
-*Note: The variable ` $KEY_NAME` is to be replaced by whatever name you desire to locally refer to your app key by.*
+_Note: The variable ` $KEY_NAME` is to be replaced by whatever name you desire to locally refer to your app key by._
 
 ### Create a new Key Pair
 
@@ -95,9 +95,9 @@ The `genesis.json` file has many options for configuration. A good summary of wh
 
 Most notably, the sections:
 
-* [Mint](https://hub.cosmos.network/main/resources/genesis.html#mint)
-* [Staking](https://hub.cosmos.network/main/resources/genesis.html#staking)
-* [Slashing](https://hub.cosmos.network/main/resources/genesis.html#slashing)
+- [Mint](https://hub.cosmos.network/main/resources/genesis.html#mint)
+- [Staking](https://hub.cosmos.network/main/resources/genesis.html#staking)
+- [Slashing](https://hub.cosmos.network/main/resources/genesis.html#slashing)
 
 ### Provide Genesis Validators Proto-Config
 
@@ -115,13 +115,13 @@ To generate the genesis transaction, we will use `uniond gentx`.
 
 The following values should be defined as follows:
 
-* `KEY_NAME` Name of the app key you created/restored earlier.
+- `KEY_NAME` Name of the app key you created/restored earlier.
 
-* `STAKE` The stake you will put down to be a validator (`10000000 <= STAKE < genesis_balance`).
+- `STAKE` The stake you will put down to be a validator (`10000000 <= STAKE < genesis_balance`).
 
-* `PUBKEY` the value returned from `uniond tendermint show-validator`
+- `PUBKEY` the value returned from `uniond tendermint show-validator`
 
-* `MONIKER` Your moniker ID.
+- `MONIKER` Your moniker ID.
 
 ```sh
 uniond gentx $KEY_NAME $STAKE "bn254" --chain-id union-testnet-1 --pubkey $PUBKEY --moniker $MONIKER
@@ -164,7 +164,6 @@ cp ~/.uniond/config/genesis.json union-testnet/
 
 After you have contributed the genesis file, genesis validators will be able to obtain the final genesis config.
 
-
 ## Genesis Validators
 
 The last step for genesis validators is to obtain the genesis configuration and overwrite their current one with it.

docs/docs/nodes-validators/running-uniond.md

@@ -1,5 +1,5 @@
 ---
-title: 'Running uniond'
+title: "Running uniond"
 ---
 
 # Running `uniond`
@@ -12,11 +12,11 @@ To run `uniond` without manually installing `nix` or NixOS, you can use docker.
 
 ## Pre-requisites
 
-* A working installation of docker
+- A working installation of docker
 
 ## Login
 
-*Note: This section will not be required once the [union](https://github.com/unionfi/union) repository is public*
+_Note: This section will not be required once the [union](https://github.com/unionfi/union) repository is public_
 
 We use the GitHub Container Registry to host our docker images. Given the [union](https://github.com/unionfi/union) repository is under a private organization, you will first need to authenticate docker with ghcr.io before downloading and running the `uniond` docker image.
 
@@ -30,7 +30,7 @@ docker login ghcr.io
 
 Supply `docker` with your GitHub username. When asked for your password, instead supply your GitHub PAT that you just created and noted.
 
-*Note: By default, `docker` will insecurely store your GitHub PAT. For alternatives, see: [docker login: Credentials Store](https://docs.docker.com/engine/reference/commandline/login/#credentials-store)*
+_Note: By default, `docker` will insecurely store your GitHub PAT. For alternatives, see: [docker login: Credentials Store](https://docs.docker.com/engine/reference/commandline/login/#credentials-store)_
 
 You should now be able to download and run docker images from ghcr.io.
 
@@ -48,7 +48,7 @@ You should now be able to run this version of `uniond` locally.
 
 Running `uniond` with `docker run` has a few caveats. These tips will help ensure you're able to accomplish everything you need with `uniond` using `docker`.
 
-* **Storing your `uniond` configuration:**
+- **Storing your `uniond` configuration:**
 
   When interacting with `uniond` it is helpful to have a persistent and accessible location to store your `uniond` configuration.
 
@@ -62,7 +62,7 @@ Running `uniond` with `docker run` has a few caveats. These tips will help ensur
   docker run --mount type=bind,source="$HOME/uniond-config",target=/uniond-config $DOCKER_FLAGS ghcr.io/unionfi/uniond:$UNIOND_VERSION $UNIOND_SUB_COMMAND --home "/uniond-config"
   ```
 
-* **Publish your docker container ports:**
+- **Publish your docker container ports:**
 
   When running a validator node, you will need to publish the necessary TCP ports to communicate with and receive request from other nodes.
 
@@ -72,5 +72,3 @@ Running `uniond` with `docker run` has a few caveats. These tips will help ensur
   # Include both ports for traffic to flow through
   docker run -p 26656:26656 -p 26657:26657 $DOCKER_FLAGS ghcr.io/unionfi/uniond:$UNIOND_VERSION $UNIOND_SUB_COMMAND
   ```
-
-

docs/docs/nodes-validators/setting-up-node.md

@@ -1,12 +1,12 @@
 ---
-title: 'Setting up a node'
+title: "Setting up a node"
 ---
 
 # Setting Up a Node
 
 This document will walk you through the process of self-hosting a Union node.
 
-# Requirements 
+# Requirements
 
 To be able to send and receive messages in the network, you'll need to conduct TCP port forwarding for ports `26656` & `26657`.
 
@@ -18,7 +18,7 @@ To be able to send and receive messages in the network, you'll need to conduct T
 
 This section will walk you through building the node binary. These instructions are different for Docker and Nix.
 
-*NOTE: It's expected that all validators/nodes use Nix or Docker to set up their node. Imperative installations are not officially supported.*
+_NOTE: It's expected that all validators/nodes use Nix or Docker to set up their node. Imperative installations are not officially supported._
 
 ## Docker
 
@@ -33,33 +33,34 @@ Run `nix build` in the root of our repository after cloning:
 nix build "github:UnionFi/union"
 ```
 -->
+
 ```sh
 nix build "git+ssh://[email protected]/UnionFi/union"
 ```
 
-*NOTE: the `uniond` executable is stored as `./result/bin/uniond`*
+_NOTE: the `uniond` executable is stored as `./result/bin/uniond`_
 
 # Environment Variables
 
 This document will often refer to environment variables you likely don't have set. You can either manually replace them before running commands, or set them before starting with the rest of the tutorial.
 
 Here's a list of the environment variables we'll use and hints for setting them:
 
-* ` $CHAIN_ID` - either `union-1` for mainnet, or `union-testnet-1` for testnet.
+- ` $CHAIN_ID` - either `union-1` for mainnet, or `union-testnet-1` for testnet.
 
   ```sh
   # Example $CHAIN_ID
   CHAIN_ID=union-testnet-1
   ```
 
-* ` $MONIKER` - The name used for your validator node.
+- ` $MONIKER` - The name used for your validator node.
 
   ```sh
   # Example $MONIKER
   MONIKER="Unionized Goblin"
   ```
 
-* ` $KEY_NAME` - The name you've assigned to the key pair you'll use for this tutorial.
+- ` $KEY_NAME` - The name you've assigned to the key pair you'll use for this tutorial.
 
   ```sh
   # Example $KEY_NAME
@@ -68,7 +69,7 @@ Here's a list of the environment variables we'll use and hints for setting them:
 
 # Connect to the Public RPC
 
-*NOTE: The public RPC is currently not available.*
+_NOTE: The public RPC is currently not available._
 
 Now to connect the `uniond` binary to the public RPC.
 
@@ -81,6 +82,7 @@ uniond config chain-id $CHAIN_ID
 Set the public RPC node:
 
 <!-- TODO: Replace `$RPC_NODE_URL` with our RPC node URL. https://github.com/UnionFi/union/issues/30 -->
+
 ```sh
 uniond config node $RPC_NODE_URL
 ```
@@ -97,9 +99,10 @@ uniond init $MONIKER "bn254" --chain-id $CHAIN_ID
 
 **`GENESIS_URL` options:**
 
-* Union Testnet: `https://raw.githubusercontent.com/unionfi/genesis/main/union-testnet-1/genesis.json`
+- Union Testnet: `https://raw.githubusercontent.com/unionfi/genesis/main/union-testnet-1/genesis.json`
 
 <!-- TODO: Create and upload genesis file for users to download. https://github.com/UnionFi/union/issues/31 -->
+
 ```sh
 curl $GENESIS_URL > ~/.union/config/genesis.json
 ```
@@ -196,5 +199,5 @@ Where `STAKE` is the amount of stake you're putting down for your validator (i.e
 
 It's then recommended to backup these files from `~/.union/config` in a secure location:
 
-* `priv_validator_key.json`
-* `node_key.json`
+- `priv_validator_key.json`
+- `node_key.json`