docs: review docs (#6590)

* fix broken CLI references
* update link to lodestar website
* some auto formatting changes

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/docusaurus.config.ts

@@ -39,7 +39,7 @@ const config: Config = {
           routeBasePath: "/",
         },
         gtag: {
-          trackingID: 'G-N21J5PWW5X',
+          trackingID: "G-N21J5PWW5X",
           anonymizeIP: true,
         },
         theme: {

docs/pages/beacon-management/networking.md

@@ -6,29 +6,29 @@ Lodestar will automatically connect to peers on the network. Peers are found thr
 
 Some of the important Lodestar flags related to networking are:
 
-- [`--discv5`](./beacon-cli.md#-discv5)
-- [`--listenAddress`](./beacon-cli.md#-listenaddress)
-- [`--port`](./beacon-cli.md#-port)
-- [`--discoveryPort`](./beacon-cli.md#-discoveryport)
-- [`--listenAddress6`](./beacon-cli.md#-listenaddress6)
-- [`--port6`](./beacon-cli.md#-port6)
-- [`--discoveryPort6`](./beacon-cli.md#-discoveryport6)
-- [`--bootnodes`](./beacon-cli.md#-bootnodes)
-- [`--deterministicLongLivedAttnets`](./beacon-cli.md#-deterministiclonglivedattnets)
-- [`--subscribeAllSubnets`](./beacon-cli.md#-subscribeallsubnets)
-- [`--disablePeerScoring`](./beacon-cli.md#-disablepeerscoring)
-- [`--enr.ip`](./beacon-cli.md#-enrip)
-- [`--enr.tcp`](./beacon-cli.md#-enrtcp)
-- [`--enr.udp`](./beacon-cli.md#-enrudp)
-- [`--enr.ip6`](./beacon-cli.md#-enrip6)
-- [`--enr.tcp6`](./beacon-cli.md#-enrtcp6)
-- [`--enr.udp6`](./beacon-cli.md#-enrudp6)
-- [`--nat`](./beacon-cli.md#-nat)
-- [`--private`](./beacon-cli.md#`-private`)
+- [`--discv5`](./beacon-cli#--discv5)
+- [`--listenAddress`](./beacon-cli#--listenaddress)
+- [`--port`](./beacon-cli#--port)
+- [`--discoveryPort`](./beacon-cli#--discoveryport)
+- [`--listenAddress6`](./beacon-cli#--listenaddress6)
+- [`--port6`](./beacon-cli#--port6)
+- [`--discoveryPort6`](./beacon-cli#--discoveryport6)
+- [`--bootnodes`](./beacon-cli#--bootnodes)
+- [`--deterministicLongLivedAttnets`](./beacon-cli#--deterministiclonglivedattnets)
+- [`--subscribeAllSubnets`](./beacon-cli#--subscribeallsubnets)
+- [`--disablePeerScoring`](./beacon-cli#--disablepeerscoring)
+- [`--enr.ip`](./beacon-cli#--enrip)
+- [`--enr.tcp`](./beacon-cli#--enrtcp)
+- [`--enr.udp`](./beacon-cli#--enrudp)
+- [`--enr.ip6`](./beacon-cli#--enrip6)
+- [`--enr.tcp6`](./beacon-cli#--enrtcp6)
+- [`--enr.udp6`](./beacon-cli#--enrudp6)
+- [`--nat`](./beacon-cli#--nat)
+- [`--private`](./beacon-cli#--private)
 
 ## Peer Discovery (Discv5)
 
-In Ethereum, discv5 plays a pivotal role in the peer discovery process, facilitating nodes to find and locate each other in order to form the peer-to-peer network​. The process begins with an interaction between new nodes and bootnodes at start-up. Bootnodes are nodes with hard-coded addresses, or can be overridden via the cli flag [`--bootnodes`](./beacon-cli.md#-bootnodes), to bootstrap the discovery process​. Through a method called FINDNODE-NODES, a new node establishes a bond with each bootnode, and it returns a list of peers for the new node to connect to. Following this trail, the new node engages through FINDNODE-NODES with the provided peers to further establish a web of connections​.
+In Ethereum, discv5 plays a pivotal role in the peer discovery process, facilitating nodes to find and locate each other in order to form the peer-to-peer network​. The process begins with an interaction between new nodes and bootnodes at start-up. Bootnodes are nodes with hard-coded addresses, or can be overridden via the cli flag [`--bootnodes`](./beacon-cli#--bootnodes), to bootstrap the discovery process​. Through a method called FINDNODE-NODES, a new node establishes a bond with each bootnode, and it returns a list of peers for the new node to connect to. Following this trail, the new node engages through FINDNODE-NODES with the provided peers to further establish a web of connections​.
 
 Discv5 operates as a peer advertisement medium in this network, where nodes can act as both providers and consumers of data. Every participating node in the Discv5 protocol discovers peer data from other nodes and later relays it, making the discovery process dynamic and efficient​.
 

docs/pages/beacon-management/syncing.md

@@ -2,7 +2,7 @@
 
 Syncing an Ethereum node involves obtaining a copy of the blockchain data from other peers in the network to reach a consistent state. This process is crucial for new nodes or nodes that have been offline and need to catch up with the network's current state. Syncing can be performed for both the execution layer and the beacon chain, although the focus here will be primarily on the beacon chain.
 
-Lodestar allows for several methods of syncing however the recommended method is `checkpoint sync` as it is the fastest and least resource intensive. It is generally a good idea to sync via a [`--checkpointSyncUrl`](./beacon-cli.md#-checkpointsyncurl). If starting at a specific point is necessary specify the [`--checkpointState`](./beacon-cli.md#-checkpointstate) that should be where the sync begins.
+Lodestar allows for several methods of syncing however the recommended method is `checkpoint sync` as it is the fastest and least resource intensive. It is generally a good idea to sync via a [`--checkpointSyncUrl`](./beacon-cli#--checkpointsyncurl). If starting at a specific point is necessary specify the [`--checkpointState`](./beacon-cli#--checkpointstate) that should be where the sync begins.
 
 ## Weak Subjectivity
 
@@ -36,7 +36,7 @@ The implementation of the different syncing styles in Lodestar are actually one
 
 There are several flags that can be used to configure the sync process.
 
-- [`--checkpointSyncUrl`](./beacon-cli.md#-checkpointsyncurl)
-- [`--checkpointState`](./beacon-cli.md#-checkpointstate)
-- [`--wssCheckpoint`](./beacon-cli.md#-wsscheckpoint)
-- [`--forceCheckpointSync`](./beacon-cli.md#-forcecheckpointsync)
+- [`--checkpointSyncUrl`](./beacon-cli#--checkpointsyncurl)
+- [`--checkpointState`](./beacon-cli#--checkpointstate)
+- [`--wssCheckpoint`](./beacon-cli#--wsscheckpoint)
+- [`--forceCheckpointSync`](./beacon-cli#--forcecheckpointsync)

docs/pages/data-retention.md

@@ -51,4 +51,4 @@ Configuring your node to store and prune data is key to success. On average you
 
 Logs can also become quite large so please check out the section on [log management](./logging-and-metrics/log-management.md) for more information.
 
-There is really only one flag that is needed to manage the data for Lodestar, [`--dataDir`](./beacon-management/beacon-cli.md#-datadir). Other than that handling log management is really the heart of the data management story. Beacon node data is what it is. Depending on the execution client that is chosen, there may be flags to help with data storage growth but that is outside the scope of this document.
+There is really only one flag that is needed to manage the data for Lodestar, [`--dataDir`](./beacon-management/beacon-cli#--datadir). Other than that handling log management is really the heart of the data management story. Beacon node data is what it is. Depending on the execution client that is chosen, there may be flags to help with data storage growth but that is outside the scope of this document.

docs/pages/getting-started/starting-a-node.md

@@ -70,7 +70,7 @@ In case execution-layer clients are available at different locations, use `--exe
 Immediately you should see confirmation that the node has started
 
 ```txt
-pr-20 15:12:45.274[]                 info: Lodestar network=mainnet, version=v1.7.2, commit=
+Apr-20 15:12:45.274[]                 info: Lodestar network=mainnet, version=v1.7.2, commit=
 Apr-20 15:12:45.327[]                 info: Connected to LevelDB database path=/data/mt1/chain-db
 Apr-20 15:12:57.747[]                 info: Initializing beacon from a valid db state slot=6264480, epoch=195765, stateRoot=0x8133cd4d0be59c3e94405f902fe0ad68ffaa5013b525dddb6285b91ad79716f6, isWithinWeakSubjectivityPeriod=true
 Apr-20 15:13:18.077[network]          info: PeerId 16Uiu2HAmDsGet67va6VCnaW2Tu1Ae2yujiDMnmURMMWNvssER7ZQ, Multiaddrs /ip4/127.0.0.1/tcp/9000/p2p/16Uiu2HAmDsGet67va6VCnaW2Tu1Ae2yujiDMnmURMMWNvssER7ZQ,/ip4/10.244.0.199/tcp/9000/p2p/16Uiu2HAmDsGet67va6VCnaW2Tu1Ae2yujiDMnmURMMWNvssER7ZQ

docs/pages/introduction.md

@@ -10,7 +10,7 @@ In Ethereum's Proof of Stake (PoS) model, validators replace miners from the Pro
 
 In an effort to promote client diversity there are several beacon-nodes being developed. Each is programmed in a different language and by a different team. The following is a list of the current beacon-node clients:
 
-- [Lodestar](https://chainsafe.io/lodestar.html)
+- [Lodestar](https://lodestar.chainsafe.io/)
 - [Prysm](https://prysmaticlabs.com/)
 - [Lighthouse](https://lighthouse.sigmaprime.io/)
 - [Teku](https://consensys.net/knowledge-base/ethereum-2/teku/)

docs/pages/validator-management/vc-configuration.md

@@ -94,7 +94,7 @@ To calculate the builder boost factor setting, you need to know what percentage
 
 Example 1: I will only accept a builder block with 25% more value than the local execution block.
 
-```
+```ts
 10000/(100+25) = 80
 ```
 

docs/sidebars.ts

@@ -1,4 +1,4 @@
-import type { SidebarsConfig } from '@docusaurus/plugin-content-docs';
+import type {SidebarsConfig} from "@docusaurus/plugin-content-docs";
 
 const sidebars: SidebarsConfig = {
   tutorialSidebar: [
@@ -70,7 +70,7 @@ const sidebars: SidebarsConfig = {
       label: "Advanced Topics",
       items: ["advanced-topics/setting-up-a-testnet"],
     },
-    "faqs"
+    "faqs",
   ],
 };