diff --git a/docs/advanced/actions.md b/docs/advanced/actions.md
index d6bd51e61..40703a55b 100644
--- a/docs/advanced/actions.md
+++ b/docs/advanced/actions.md
@@ -510,8 +510,8 @@ export interface ActionParameter {
 
 The `pattern` should be a string equivalent of a valid regular expression. This
 regular expression pattern should by used by blink-clients to validate user
-input before making the POST request. If the `pattern` is not a valid
-regular expression, it should be ignored by clients.
+input before making the POST request. If the `pattern` is not a valid regular
+expression, it should be ignored by clients.
 
 The `patternDescription` is a human readable description of the expected input
 requests from the user. If `pattern` is provided, the `patternDescription` is
@@ -971,9 +971,9 @@ clients in one of the following ways:
   UI with the included Action metadata, but will not allow the user to execute
   further actions.
 
-If `links.next` is not provided, blink clients should assume the current
-action is final action in the chain, presenting their "completed" UI state after
-the transaction is confirmed.
+If `links.next` is not provided, blink clients should assume the current action
+is final action in the chain, presenting their "completed" UI state after the
+transaction is confirmed.
 
 ## actions.json
 
@@ -1070,9 +1070,8 @@ The following table outlines the syntax for path matching patterns:
 
 ### Rules Examples
 
-The following example demonstrates an exact match rule to map requests
-to `/buy` from your site's root to the exact path `/api/buy` relative to your
-site's root:
+The following example demonstrates an exact match rule to map requests to `/buy`
+from your site's root to the exact path `/api/buy` relative to your site's root:
 
 ```json filename="actions.json"
 {
diff --git a/docs/advanced/retry.md b/docs/advanced/retry.md
index eb650a099..dfea6dac3 100644
--- a/docs/advanced/retry.md
+++ b/docs/advanced/retry.md
@@ -142,13 +142,13 @@ transaction submission if developers enable
 
 ![Transaction dropped via an RPC Pool](/assets/docs/rt-dropped-via-rpc-pool.png)
 
-Temporary network forks can also result in dropped transactions. If a
-validator is slow to replay its blocks within the Banking Stage, it may end up
-creating a minority fork. When a client builds a transaction, it's possible for
-the transaction to reference a `recentBlockhash` that only exists on the
-minority fork. After the transaction is submitted, the cluster can then switch
-away from its minority fork before the transaction is processed. In this
-scenario, the transaction is dropped due to the blockhash not being found.
+Temporary network forks can also result in dropped transactions. If a validator
+is slow to replay its blocks within the Banking Stage, it may end up creating a
+minority fork. When a client builds a transaction, it's possible for the
+transaction to reference a `recentBlockhash` that only exists on the minority
+fork. After the transaction is submitted, the cluster can then switch away from
+its minority fork before the transaction is processed. In this scenario, the
+transaction is dropped due to the blockhash not being found.
 
 ![Transaction dropped due to minority fork (before processed)](/assets/docs/rt-dropped-minority-fork-pre-process.png)
 
diff --git a/docs/advanced/state-compression.md b/docs/advanced/state-compression.md
index b0cc2e34a..5e01a602e 100644
--- a/docs/advanced/state-compression.md
+++ b/docs/advanced/state-compression.md
@@ -94,9 +94,9 @@ In high throughput applications, like within the
 [Solana runtime](/docs/core/fees.md), requests to change an on-chain
 _traditional merkle tree_ could be received by validators in relatively rapid
 succession (e.g. within the same slot). Each leaf data change would still be
-required to be performed in series. Resulting in each subsequent request for change
-to fail, due to the root hash and proof being invalidated by the previous change
-request in the slot.
+required to be performed in series. Resulting in each subsequent request for
+change to fail, due to the root hash and proof being invalidated by the previous
+change request in the slot.
 
 Enter, Concurrent merkle trees.
 
@@ -175,8 +175,8 @@ We must use a `maxDepth` of `14` to ensure we can store all of our data.
 
 The `maxDepth` value will be one of the primary drivers of cost when creating a
 tree since you will pay this cost upfront at tree creation. The higher the max
-tree depth, the more data fingerprints (aka hashes) you can store, the
-higher the cost.
+tree depth, the more data fingerprints (aka hashes) you can store, the higher
+the cost.
 
 ### Max buffer size
 
diff --git a/docs/core/pda.md b/docs/core/pda.md
index 76f369b02..2d0330554 100644
--- a/docs/core/pda.md
+++ b/docs/core/pda.md
@@ -46,8 +46,8 @@ anything built at that location.
 - PDAs are addresses that fall off the Ed25519 curve and have no corresponding
   private key.
 
-- Solana programs can programmatically "sign" on behalf of PDAs that are derived using
-  its program ID.
+- Solana programs can programmatically "sign" on behalf of PDAs that are derived
+  using its program ID.
 
 - Deriving a PDA does not automatically create an on-chain account.
 
diff --git a/tsconfig.json b/tsconfig.json
index d90767bb3..5f9e81ca6 100644
--- a/tsconfig.json
+++ b/tsconfig.json
@@ -18,20 +18,20 @@
     "paths": {
       "contentlayer/generated": ["./.contentlayer/generated"],
       "@/*": ["./src/*"],
-      "@@/*": ["./*"],
+      "@@/*": ["./*"]
     },
     "plugins": [
       {
-        "name": "next",
-      },
-    ],
+        "name": "next"
+      }
+    ]
   },
   "include": [
     ".contentlayer/generated",
     "next-env.d.ts",
     "**/*.ts",
     "**/*.tsx",
-    ".next/types/**/*.ts",
+    ".next/types/**/*.ts"
   ],
-  "exclude": ["node_modules", "code"],
+  "exclude": ["node_modules", "code"]
 }