docs: update links for graph tooling repo (#4303)

docs: update links for graph tooling repo

dependabot: weekly yarn.lock upgrade

rebuild lockfile

update lockfiles

fixes

Author: saihaj

.github/dependabot.yml

@@ -1,5 +1,17 @@
 version: 2
 updates:
+
+- package-ecosystem: npm
+  directory: tests/integration-tests
+  schedule:
+    interval: weekly
+  open-pull-requests-limit: 10
+  allow:
+    # We always want to test against the latest Graph CLI tooling: `graph-cli`,
+    # `graph-ts`.
+    - dependency-name: "@graphprotocol/graph-*"
+  versioning-strategy: lockfile-only
+
 - package-ecosystem: cargo
   directory: "/"
   schedule:

.github/workflows/ci.yml

@@ -102,10 +102,10 @@ jobs:
         uses: actions/checkout@v2
       - uses: Swatinem/rust-cache@v2
 
-      - name: Install Node 14
+      - name: Install Node 16
         uses: actions/setup-node@v3
         with:
-          node-version: "14"
+          node-version: "16"
           cache: yarn
           cache-dependency-path: "tests/integration-tests/yarn.lock"
 

docker/README.md

@@ -59,7 +59,7 @@ can access these via:
   - `postgresql://graph-node:let-me-in@localhost:5432/graph-node`
 
 Once this is up and running, you can use
-[`graph-cli`](https://github.com/graphprotocol/graph-cli) to create and
+[`graph-cli`](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) to create and
 deploy your subgraph to the running Graph Node.
 
 ### Running Graph Node on an Macbook M1

docs/getting-started.md

@@ -43,7 +43,7 @@ The high-level dataflow for a dApp using The Graph is as follows:
 ### 0.3 What's Needed to Build a Graph Node?
 Three repositories are relevant to building on The Graph:
 1. [Graph Node](../README.md) – A server implementation for indexing, caching, and serving queries against data from Ethereum.
-2. [Graph CLI](https://github.com/graphprotocol/graph-cli) – A CLI for building and compiling projects that are deployed to the Graph Node.
+2. [Graph CLI](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) – A CLI for building and compiling projects that are deployed to the Graph Node.
 3. [Graph TypeScript Library](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) – TypeScript/AssemblyScript library for writing subgraph mappings to be deployed to The Graph.
 
 ### 0.4 Getting Started Overview
@@ -182,9 +182,9 @@ schema:
 ```
 
 ### 1.3 Create a Subgraph Project and Generate Types
-Once you have the `subgraph.yaml` manifest and the `./schema.graphql` file, you are ready to use the Graph CLI to set up the subgraph directory. The Graph CLI is a command-line tool that contains helpful commands for deploying the subgraphs. Before continuing with this guide, please go to the [Graph CLI README](https://github.com/graphprotocol/graph-cli/) and follow the instructions up to Step 7 for setting up the subgraph directory.
+Once you have the `subgraph.yaml` manifest and the `./schema.graphql` file, you are ready to use the Graph CLI to set up the subgraph directory. The Graph CLI is a command-line tool that contains helpful commands for deploying the subgraphs. Before continuing with this guide, please go to the [Graph CLI README](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) and follow the instructions up to Step 7 for setting up the subgraph directory.
 
-Once you run `yarn codegen` as outlined in the [Graph CLI README](https://github.com/graphprotocol/graph-cli/), you are ready to create the mappings.
+Once you run `yarn codegen` as outlined in the [Graph CLI README](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli), you are ready to create the mappings.
 
 `yarn codegen` looks at the contract ABIs defined in the subgraph manifest and generates TypeScript classes for the smart contracts the mappings script will interface with, which includes the types of public methods and events. In reality, the classes are AssemblyScript but more on that later.
 
@@ -228,7 +228,7 @@ export function handleTransfer(event: Transfer): void {
 ```
 A few things to note from this code:
 * We create a new entity named `token`, which is stored in the Graph Node database.
-* We create an ID for that token, which must be unique, and then create an entity with `new Token(tokenID)`. We get the token ID from the event emitted by Ethereum, which was turned into an AssemblyScript type by the [Graph TypeScript Library](https://github.com/graphprotocol/graph-ts). We access it at `event.params.tokenId`. Note that you must set `ID` as a string and call `toHex()` on the `tokenID` to turn it into a hex string.
+* We create an ID for that token, which must be unique, and then create an entity with `new Token(tokenID)`. We get the token ID from the event emitted by Ethereum, which was turned into an AssemblyScript type by the [Graph TypeScript Library](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts). We access it at `event.params.tokenId`. Note that you must set `ID` as a string and call `toHex()` on the `tokenID` to turn it into a hex string.
 * This entity is updated by the `Transfer` event emitted by the ERC721 contract.
 * The current owner is gathered from the event with `event.params.to`. It is set as an Address by the Token class.
 * Event handlers functions always return `void`.
@@ -252,7 +252,7 @@ The definition for `<entity>.load()` is:
 entity.load() // Entity is representative of the entity type being updated. In our example above, it is Token.
 ```
 
-Once again, all these functions come from the [Graph TypeScript Library](https://github.com/graphprotocol/graph-ts).
+Once again, all these functions come from the [Graph TypeScript Library](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts).
 
 Let's look at the ERC721 token as an example for using `token.load()`. Above, we showed how to use `token.save()`. Now, let's consider that you have another event handler that needs to retrieve the currentOwner of an ERC721 token. To do this within an event handler, you would write the following:
 
@@ -407,7 +407,7 @@ If you want to sync using a public testnet such as Kovan, Rinkeby, or Ropsten, j
 
 When you deploy the subgraph to the Graph Node, it will start ingesting all the subgraph events from the blockchain, transforming that data with the subgraph mappings and storing it in the Graph Node. Note that a running subgraph can safely be stopped and restarted, picking up where it left off.
 
-Now that the infrastructure is set up, you can run `yarn create-subgraph` and then `yarn deploy` in the subgraph directory. These commands should have been added to `package.json` in section 1.3 when we took a moment to go through the set up for [Graph CLI documentation](https://github.com/graphprotocol/graph-cli). This builds the subgraph and creates the WASM files in the `dist/` folder. Next, it uploads the `dist/
+Now that the infrastructure is set up, you can run `yarn create-subgraph` and then `yarn deploy` in the subgraph directory. These commands should have been added to `package.json` in section 1.3 when we took a moment to go through the set up for [Graph CLI documentation](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli). This builds the subgraph and creates the WASM files in the `dist/` folder. Next, it uploads the `dist/
 ` files to IPFS and deploys it to the Graph Node. The subgraph is now fully running.
 
 The `watch` flag allows the subgraph to continually restart every time you save an update to the `manifest`, `schema`, or `mappings`. If you are making many edits or have a subgraph that has been syncing for a few hours, leave this flag off.

docs/implementation/add-chain.md

@@ -256,22 +256,22 @@ Just like in the `server` crate, you'll just have to handle the new `BlockchainK
 
 ## What else?
 
-Besides making `graph-node` support the new chain, [graph-cli](https://github.com/graphprotocol/graph-cli) and [graph-ts](https://github.com/graphprotocol/graph-ts) should also include the new types and enable the new functionality so that subgraph developers can use it.
+Besides making `graph-node` support the new chain, [graph-cli](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli) and [graph-ts](https://github.com/graphprotocol/graph-tooling/tree/main/packages/ts) should also include the new types and enable the new functionality so that subgraph developers can use it.
 
 For now this document doesn't include how to do that integration, here are a few PRs that might help you with that:
 
 - NEAR
   - `graph-cli`
-    - https://github.com/graphprotocol/graph-cli/pull/760
-    - https://github.com/graphprotocol/graph-cli/pull/783
+    - https://github.com/graphprotocol/graph-tooling/pull/760
+    - https://github.com/graphprotocol/graph-tooling/pull/783
   - `graph-ts`
     - https://github.com/graphprotocol/graph-ts/pull/210
     - https://github.com/graphprotocol/graph-ts/pull/217
 - Cosmos
   - `graph-cli`
-    - https://github.com/graphprotocol/graph-cli/pull/827
-    - https://github.com/graphprotocol/graph-cli/pull/851
-    - https://github.com/graphprotocol/graph-cli/pull/888
+    - https://github.com/graphprotocol/graph-tooling/pull/827
+    - https://github.com/graphprotocol/graph-tooling/pull/851
+    - https://github.com/graphprotocol/graph-toolingpull/888
   - `graph-ts`
     - https://github.com/graphprotocol/graph-ts/pull/250
     - https://github.com/graphprotocol/graph-ts/pull/273

docs/subgraph-manifest.md

@@ -34,7 +34,7 @@ Any data format that has a well-defined 1:1 mapping with the [IPLD Canonical For
 | --- | --- | --- |
 | **kind** | *String | The type of data source. Possible values: *ethereum/contract*.|
 | **name** | *String* | The name of the source data. Will be used to generate APIs in the mapping and also for self-documentation purposes. |
-| **network** | *String* | For blockchains, this describes which network the subgraph targets. For Ethereum, this can be any of "mainnet", "rinkeby", "kovan", "ropsten", "goerli", "poa-core", "poa-sokol", "xdai", "matic", "mumbai", "fantom", "bsc" or "clover". Developers could look for an up to date list in the graph-cli [*code*](https://github.com/graphprotocol/graph-cli/blob/main/packages/cli/src/protocols/index.js#L70-L107).|
+| **network** | *String* | For blockchains, this describes which network the subgraph targets. For Ethereum, this can be any of "mainnet", "rinkeby", "kovan", "ropsten", "goerli", "poa-core", "poa-sokol", "xdai", "matic", "mumbai", "fantom", "bsc" or "clover". Developers could look for an up to date list in the graph-cli [*code*](https://github.com/graphprotocol/graph-tooling/blob/main/packages/cli/src/protocols/index.ts#L76-L117).|
 | **source** | [*EthereumContractSource*](#151-ethereumcontractsource) | The source data on a blockchain such as Ethereum. |
 | **mapping** | [*Mapping*](#152-mapping) | The transformation logic applied to the data prior to being indexed. |
 

runtime/test/README.md

@@ -1,6 +1,6 @@
 # Runtime tests
 
-These are the unit tests that check if the WASM runtime code is working. For now we only run code compiled from the [`AssemblyScript`](https://www.assemblyscript.org/) language, which is done by [`asc`](https://github.com/AssemblyScript/assemblyscript) (the AssemblyScript Compiler) in our [`CLI`](https://github.com/graphprotocol/graph-cli).
+These are the unit tests that check if the WASM runtime code is working. For now we only run code compiled from the [`AssemblyScript`](https://www.assemblyscript.org/) language, which is done by [`asc`](https://github.com/AssemblyScript/assemblyscript) (the AssemblyScript Compiler) in our [`CLI`](https://github.com/graphprotocol/graph-tooling/tree/main/packages/cli).
 
 We support two versions of their compiler/language for now:
 

tests/integration-tests/api-version-v0-0-4/package.json

@@ -8,6 +8,7 @@
     "create:test": "graph create test/api-version-v0-0-4 --node $GRAPH_NODE_ADMIN_URI",
     "deploy:test": "graph deploy test/api-version-v0-0-4 --version-label v0.0.1 --ipfs $IPFS_URI --node $GRAPH_NODE_ADMIN_URI"
   },
+  "note": "Do not update the dependencies below - we want to make sure it's backward comaptible, so we are using an old CLI version on purpose.",
   "devDependencies": {
     "@graphprotocol/graph-cli": "https://github.com/graphprotocol/graph-cli#v0.21.1",
     "@graphprotocol/graph-ts": "https://github.com/graphprotocol/graph-ts#v0.21.1",

tests/integration-tests/ganache-reverts/package.json

@@ -9,8 +9,8 @@
     "deploy:test": "graph deploy test/ganache-reverts --version-label v0.0.1 --ipfs $IPFS_URI --node $GRAPH_NODE_ADMIN_URI"
   },
   "devDependencies": {
-    "@graphprotocol/graph-cli": "https://github.com/graphprotocol/graph-cli#main",
-    "@graphprotocol/graph-ts": "https://github.com/graphprotocol/graph-ts#main",
+    "@graphprotocol/graph-cli": "0.50.0",
+    "@graphprotocol/graph-ts": "0.30.0",
     "solc": "^0.8.2"
   },
   "dependencies": {

tests/integration-tests/ganache-reverts/subgraph.yaml

@@ -1,4 +1,4 @@
-specVersion: 0.0.2
+specVersion: 0.0.4
 schema:
   file: ./schema.graphql
 dataSources:
@@ -10,7 +10,7 @@ dataSources:
       abi: Contract
     mapping:
       kind: ethereum/events
-      apiVersion: 0.0.5
+      apiVersion: 0.0.6
       language: wasm/assemblyscript
       abis:
         - name: Contract