Update dependencies + run pnpm check:fix

Author: benface

package.json

@@ -2,7 +2,7 @@
   "name": "graph-docs",
   "private": true,
   "version": "1.0.0",
-  "packageManager": "pnpm@10.12.1",
+  "packageManager": "pnpm@10.12.2",
   "scripts": {
     "dev": "turbo run dev",
     "build": "NODE_OPTIONS='--max_old_space_size=8192' turbo run build",
@@ -21,11 +21,11 @@
   },
   "devDependencies": {
     "@edgeandnode/eslint-config": "^2.0.3",
-    "@types/node": "^22.15.31",
+    "@types/node": "^22.15.32",
     "eslint": "^8.57.1",
-    "eslint-plugin-mdx": "^3.4.2",
-    "prettier": "^3.5.3",
-    "prettier-plugin-tailwindcss": "^0.6.12",
+    "eslint-plugin-mdx": "^3.5.0",
+    "prettier": "^3.6.0",
+    "prettier-plugin-tailwindcss": "^0.6.13",
     "remark-frontmatter": "^5.0.0",
     "remark-lint-first-heading-level": "^4.0.1",
     "remark-lint-heading-increment": "^4.0.1",

packages/og-image/package.json

@@ -16,10 +16,10 @@
     "yoga-wasm-web": "^0.3.3"
   },
   "devDependencies": {
-    "@cloudflare/workers-types": "^4.20250610.0",
+    "@cloudflare/workers-types": "^4.20250620.0",
     "@types/react": "^18.3.23",
     "jest-image-snapshot": "^6.5.1",
-    "tsx": "^4.19.4",
+    "tsx": "^4.20.3",
     "typescript": "^5.8.3",
     "vitest": "^2.1.9",
     "wrangler": "^3.114.9"

pnpm-lock.yaml

@@ -19,19 +19,19 @@
   "dependencies": {
     "@docsearch/react": "^3.9.0",
     "@edgeandnode/common": "^7.0.4",
-    "@edgeandnode/gds": "^6.5.15",
-    "@edgeandnode/go": "^10.1.1",
+    "@edgeandnode/gds": "^6.6.1",
+    "@edgeandnode/go": "^10.2.2",
     "@emotion/react": "^11.14.0",
-    "@graphprotocol/contracts": "^7.1.2",
+    "@graphprotocol/contracts": "^7.3.0",
     "@pinax/graph-networks-registry": "^0.6.7",
     "@react-hookz/web": "^25.1.1",
     "@readme/httpsnippet": "^11.0.0",
     "@readme/openapi-parser": "^4.1.0",
     "fetch-har": "^11.1.1",
     "lodash": "^4.17.21",
     "mixpanel-browser": "^2.65.0",
-    "motion": "^12.16.0",
-    "next": "^14.2.29",
+    "motion": "^12.19.1",
+    "next": "^14.2.30",
     "next-seo": "^6.8.0",
     "next-sitemap": "^4.2.3",
     "nextra": "^3.3.1",
@@ -45,20 +45,20 @@
     "remark-callouts": "workspace:*",
     "theme-ui": "^0.17.2",
     "unist-util-visit": "^5.0.0",
-    "zod": "^3.25.57"
+    "zod": "^3.25.67"
   },
   "devDependencies": {
-    "@types/lodash": "^4.17.17",
+    "@types/lodash": "^4.17.18",
     "@types/mdast": "^4.0.4",
     "@types/mixpanel-browser": "^2.60.0",
-    "@types/node": "^22.15.31",
+    "@types/node": "^22.15.32",
     "@types/react": "^18.3.23",
     "@types/react-dom": "^18.3.7",
     "autoprefixer": "^10.4.21",
     "fast-xml-parser": "^5.2.5",
-    "postcss": "^8.5.4",
+    "postcss": "^8.5.6",
     "tailwindcss": "^3.4.17",
     "tsup": "^8.5.0",
-    "tsx": "^4.19.4"
+    "tsx": "^4.20.3"
   }
 }

website/package.json

@@ -25,7 +25,6 @@ The Graph’s billing system accepts GRT on Arbitrum, and users will need ETH on
 Consequently, to pay for queries, you need GRT on Arbitrum. Here are a few different ways to achieve this:
 
 - If you already have GRT on Ethereum, you can bridge it to Arbitrum. You can do this via the GRT bridging option provided in Subgraph Studio or by using one of the following bridges:
-
   - [The Arbitrum Bridge](https://bridge.arbitrum.io/?l2ChainId=42161)
   - [TransferTo](https://transferto.xyz/swap)
 

website/src/pages/ar/archived/arbitrum/arbitrum-faq.mdx

@@ -680,13 +680,11 @@ graph indexer actions execute approve
 Note that supported action types for allocation management have different input requirements:
 
 - `Allocate` - allocate stake to a specific Subgraph deployment
-
   - required action params:
     - deploymentID
     - amount
 
 - `Unallocate` - close allocation, freeing up the stake to reallocate elsewhere
-
   - required action params:
     - allocationID
     - deploymentID
@@ -695,7 +693,6 @@ Note that supported action types for allocation management have different input
     - force (forces using the provided POI even if it doesn’t match what the graph-node provides)
 
 - `Reallocate` - atomically close allocation and open a fresh allocation for the same Subgraph deployment
-
   - required action params:
     - allocationID
     - deploymentID

website/src/pages/ar/indexing/overview.mdx

@@ -38,7 +38,6 @@ As long as you run `tap-agent` and `indexer-agent`, everything will be executed
 3. `indexer-agent` takes all the last RAVS and sends redeem requests to the blockchain, which will update the value of `redeem_at`.
 
 4. During the `<finality-time>` period, `indexer-agent` monitors if the blockchain has any reorganizations that revert the transaction.
-
    - If it was reverted, the RAV is resent to the blockchain. If it was not reverted, it gets marked as `final`.
 
 ## Blockchain Addresses
@@ -77,17 +76,14 @@ The required software version can be found [here](https://github.com/graphprotoc
 ### Steps
 
 1. **Indexer Agent**
-
    - Follow the [same process](https://github.com/graphprotocol/indexer/pkgs/container/indexer-agent#graph-protocol-indexer-components).
    - Give the new argument `--tap-subgraph-endpoint` to activate the new GraphTally codepaths and enable redeeming of RAVs.
 
 2. **Indexer Service**
-
    - Fully replace your current configuration with the [new Indexer Service rs](https://github.com/graphprotocol/indexer-rs). It's recommend that you use the [container image](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
    - Like the older version, you can scale Indexer Service horizontally easily. It is still stateless.
 
 3. **TAP Agent**
-
    - Run _one_ single instance of [TAP Agent](https://github.com/graphprotocol/indexer-rs) at all times. It's recommend that you use the [container image](https://github.com/orgs/graphprotocol/packages?repo_name=indexer-rs).
 
 4. **Configure Indexer Service and TAP Agent**

website/src/pages/ar/indexing/tap.mdx

@@ -15,7 +15,6 @@ title: قائمة المصطلحات
 - **Indexer**: Network participants that run indexing nodes to index data from blockchains and serve GraphQL queries.
 
 - **Indexer Revenue Streams**: Indexers are rewarded in GRT with two components: query fee rebates and indexing rewards.
-
   1. **Query Fee Rebates**: Payments from Subgraph consumers for serving queries on the network.
 
   2. **Indexing Rewards**: The rewards that Indexers receive for indexing Subgraphs. Indexing rewards are generated via new issuance of 3% GRT annually.
@@ -43,7 +42,6 @@ title: قائمة المصطلحات
 - **Epoch**: A unit of time within the network. Currently, one epoch is 6,646 blocks or approximately 1 day.
 
 - **Allocation**: An Indexer can allocate their total GRT stake (including Delegators' stake) towards Subgraphs that have been published on The Graph's decentralized network. Allocations can have different statuses:
-
   1. **Active**: An allocation is considered active when it is created onchain. This is called opening an allocation, and indicates to the network that the Indexer is actively indexing and serving queries for a particular Subgraph. Active allocations accrue indexing rewards proportional to the signal on the Subgraph, and the amount of GRT allocated.
 
   2. **Closed**: An Indexer may claim the accrued indexing rewards on a given Subgraph by submitting a recent, and valid, Proof of Indexing (POI). This is known as closing an allocation. An allocation must have been open for a minimum of one epoch before it can be closed. The maximum allocation period is 28 epochs. If an Indexer leaves an allocation open beyond 28 epochs, it is known as a stale allocation. When an allocation is in the **Closed** state, a Fisherman can still open a dispute to challenge an Indexer for serving false data.

website/src/pages/ar/resources/glossary.mdx

@@ -13,13 +13,11 @@ Learn how to withdraw your delegated tokens through [Graph Explorer](https://the
 1. Visit [Graph Explorer](https://thegraph.com/explorer). Please make sure you're on Explorer and **not** Subgraph Studio.
 
 2. Click on your profile. You can find it on the top right corner of the page.
-
    - Make sure that your wallet is connected. If it's not connected, you will see the "connect" button instead.
 
 3. Once you're in your profile, click on the Delegating tab. In the Delegating tab, you can view the list of Indexers you have delegated to.
 
 4. Click on the Indexer from which you wish to withdraw your tokens.
-
    - Make sure to note the specific Indexer, as you will need to find them again to withdraw.
 
 5. Select the "Undelegate" option by clicking on the three dots next to the Indexer on the right side, see image below:
@@ -37,11 +35,9 @@ Learn how to withdraw your delegated tokens through [Graph Explorer](https://the
 ### Step-by-Step
 
 1. Find your delegation transaction on Arbiscan.
-
    - Here's an [example transaction on Arbiscan](https://arbiscan.io/tx/0xcf2110eac897099f821064445041031efb32786392bdbe7544a4cb7a6b2e4f9a)
 
 2. Navigate to "Transaction Action" where you can find the staking extension contract:
-
    - [This is the staking extension contract for the example listed above](https://arbiscan.io/address/0x00669A4CF01450B64E8A2A20E9b1FCB71E61eF03)
 
 3. Then click on "Contract". ![Contract tab on Arbiscan, between NFT Transfers and Events](/img/arbiscan-contract.png)
@@ -59,7 +55,6 @@ Learn how to withdraw your delegated tokens through [Graph Explorer](https://the
 9. If you don't know how many tokens you delegated, you can call `getDelegation` on the Read Custom tab. You will need to paste your address (delegator address) and the address of the Indexer that you delegated to, as shown in the following screenshot:
 
    ![Both of the addresses needed](/img/get-delegate.png)
-
    - This will return three numbers. The first number is the amount you can unstake.
 
 10. After you have called `unstake`, you can withdraw after approximately 28 epochs (28 days) by calling the `withdraw` function.

website/src/pages/ar/resources/roles/delegating/undelegating.mdx

@@ -14,12 +14,10 @@ This feature enables quick deployment of hotfixes for critical issues, eliminati
 ## Benefits of Grafting for Hotfixes
 
 1. **Rapid Deployment**
-
    - **Minimize Downtime**: When a Subgraph encounters a critical error and stops indexing, grafting enables you to deploy a fix immediately without waiting for re-indexing.
    - **Immediate Recovery**: The new Subgraph continues from the last indexed block, ensuring that data services remain uninterrupted.
 
 2. **Data Preservation**
-
    - **Reuse Historical Data**: Grafting copies the existing data from the base Subgraph, so you don’t lose valuable historical records.
    - **Consistency**: Maintains data continuity, which is crucial for applications relying on consistent historical data.
 
@@ -30,19 +28,16 @@ This feature enables quick deployment of hotfixes for critical issues, eliminati
 ## Best Practices When Using Grafting for Hotfixes
 
 1. **Initial Deployment Without Grafting**
-
    - **Start Clean**: Always deploy your initial Subgraph without grafting to ensure that it’s stable and functions as expected.
    - **Test Thoroughly**: Validate the Subgraph’s performance to minimize the need for future hotfixes.
 
 2. **Implementing the Hotfix with Grafting**
-
    - **Identify the Issue**: When a critical error occurs, determine the block number of the last successfully indexed event.
    - **Create a New Subgraph**: Develop a new Subgraph that includes the hotfix.
    - **Configure Grafting**: Use grafting to copy data up to the identified block number from the failed Subgraph.
    - **Deploy Quickly**: Publish the grafted Subgraph to restore service as soon as possible.
 
 3. **Post-Hotfix Actions**
-
    - **Monitor Performance**: Ensure the grafted Subgraph is indexing correctly and the hotfix resolves the issue.
    - **Republish Without Grafting**: Once stable, deploy a new version of the Subgraph without grafting for long-term maintenance.
      > Note: Relying on grafting indefinitely is not recommended as it can complicate future updates and maintenance.
@@ -130,7 +125,6 @@ Suppose you have a Subgraph tracking a smart contract that has stopped indexing
   - **block**: Block number where grafting should begin.
 
 3. **Deployment Steps**
-
    - **Update the Code**: Implement the hotfix in your mapping scripts (e.g., handleWithdrawal).
    - **Adjust the Manifest**: As shown above, update the `subgraph.yaml` with grafting configurations.
    - **Deploy the Subgraph**: