Rewrite graph-cli in Rust

[lutter]

This is all Claude-generated code, I haven't even looked at it or tried it. It's mostly here for informational purposes

[dimitrovmaksim]

Couple of things I noticed for the commands that i'm familiar with:

1. test
   • It expects matchstick to be a node_module installed via matchstick-as (the equivalent of graph-ts for matchstick). In the ts graph-cli we used a lib to download and execute binaries, so it probably got confused by that.
     EDIT: I now see that the binaryinstall lib was removed and the matchstick bin was directly fetched from the repo into node_modules/.bin/, but I don't see the test command doing it here
   • I would probably remove the binary path and leave only the Docker path, or at least make it the default (or phase out the test command completelly)
2. add
   • By default the add command indexes events as entities. This caused some issues with duplicated entities and abi overwrites. If there were collision in event/entity names with existing events/entity names it would prepend the new entity name with the contract name. It seems that Claude has cut that whole logic off and just ignores collsions, unless the --merge-entities flag is passed. IMO this descision back then caused more trouble than benefit, so I would remove the code that touches the schema with the add command and leave this to the developer. Anyways it seems rare that entites match events 1:1.
   • the to_kebab_case function seems to not handle some cases correctly

     graph-node/gnd/src/commands/add.rs

     Line 658 in 5c086e6

     assert_eq!(to_kebab_case("ERC20Token"), "e-r-c20-token");

     (i would expect the result in this case to be either erc-20-token or erc20-token in the best case scenario). The TS cli uses the gluegun/loadash implementation for kebabCase

[dimitrovmaksim]

Differences and regressions I noticed compared to the graph-cli when running init interactively with the Smart Contract source

1. Step ordering
   Some prompts are ordered differently (for example, subgraph slug and directory).
   I actually think the gnd order makes more sense here, since it may allow suggestions based on the fetched contract information.

2. Contract info fetching (regression)
   In graph-cli, contract information is fetched immediately after the contract address is entered. The CLI then suggests the fetched contract name, start block, and would prompt for ABI path only if fetching fails.
   In gnd, these values are prompted before fetching the contract info, and later, it appears that the fetched data is not used and the defaults or user input are kept instead.
   (I’ve added code snippets below showing the step order in both CLIs.)

3. Adding additional contracts
   graph-cli prompts the user at the end of init to add another contract, while gnd does not.

graph-cli:

$ graph init
✔ Network · Arbitrum One Mainnet · arbitrum-one · https://arbiscan.io
✔ Source · Smart Contract · ethereum
✔ Subgraph slug · graph-token
✔ Directory to create the subgraph in · graph-token
✔ Contract address · 0x9623063377AD1B27544C965cCd7342f7EA7e88C7
✔ Fetching ABI from Sourcify API...
✔ Fetching ABI from Contract API...
✔ Fetching start block from Contract API...
✔ Fetching contract name from Contract API...
✔ Start block · 42449274
✔ Contract name · GraphProxy
✔ Index contract events as entities (Y/n) · false
  Generate subgraph
  Write subgraph to directory
✔ Create subgraph scaffold
✔ Initialize networks config
✔ Initialize subgraph repository
✔ Install dependencies with yarn
✔ Generate ABI and schema types with yarn codegen
✔ Add another contract? (y/N) · false

Subgraph graph-token created in graph-token

gnd:

$ gnd init
Creating a new subgraph...

> Source: Smart contract
> Network: Arbitrum One Mainnet (arbitrum-one)
> Contract address: 0x9623063377AD1B27544C965cCd7342f7EA7e88C7
> Contract name: Contract
> Subgraph slug: contract
> Directory: contract
> Do you have an ABI file? No
> Start block: 0
> Index contract events as entities? No
→ Fetching contract info from 0x9623063377AD1B27544C965cCd7342f7EA7e88C7 on arbitrum-one
✔ Found contract: GraphProxy
→ Generating scaffold files
→ Initializing Git repository
✔ Install dependencies with pnpm
✔ Subgraph created at contract

Next steps:
  cd contract
  gnd codegen
  gnd build

4. Directory name collisions
   If the target directory already exists, graph-cli asks whether it should be overwritten.
   gnd exits with an error instead. While this may not strictly be a regression, I think it would make more sense to prompt the user to choose a different directory name to avoid the collision.

5. Obsolete spkg flag
   Not a regression, but gnd still exposes the spkg flag, which appears to be obsolete now that SPS is deprecated and the Substreams option has been removed.

6. gnd does not create the networks.json file with the chain info, that is used for deploying the subgraph to multiple networks

{
  "arbitrum-one": {
    "GraphProxy": {
      "address": "0x9623063377AD1B27544C965cCd7342f7EA7e88C7",
      "startBlock": 42449274
    }
  }
}

I’ll follow up with additional comments if I find any more differences or regressions.

[dimitrovmaksim]

Two more things i noticed for init:

1. gnd will add the contract address as a hex number in the manifest, instead of as a string

# gnd
source:
    abi: Graph
    address: 0x9623063377AD1B27544C965cCd7342f7EA7e88C7

# graph-cli
    source:
      address: "0x9623063377AD1B27544C965cCd7342f7EA7e88C7"

2. gnd, when scaffolding the manifest, will add the mappings file without prependign ./src so it will only contain the mappings file name. https://github.com/graphprotocol/graph-node/blob/lutter/gnd-cli/gnd/src/scaffold/manifest.rs#L9
   The add command on the other hand, correctly prepends src

# gnd
...
     file: ./graph.ts
...

# graph-cli
...
      file: ./src/graph-proxy.ts
...

So graph-cli won't be able to work with gnd generated subgraphs:

✖ Failed to load subgraph from subgraph.yaml: Error in subgraph.yaml:

  Path: dataSources > 0 > source > address
  Expected string, found number:
  8.571296818927177e+47

  Path: dataSources > 0 > mapping > file
  File does not exist: graph.ts

  Path: dataSources > 1 > source > address
  Expected string, found number:
  1.0021244402728634e+48

Also gnd build will fail, as it expects the path to contain ./src

Manifest validation errors:
  - Mapping file for data source 'Graph' not found: ./graph.ts

[dimitrovmaksim]

For the add command (in addition to what is mentioned here #6282 (comment))

1. In gnd the add command accepts a --network flag, which in the case of add does not make sense, as subgraphs do not support multichain datasources, so the chain should always be derived from the manifest file. I guess Claude got confused here and added --network instead of --network-file, which should be the path to the networks config file (if a custom one is used).
2. Similar to init, add does not update the networks file and this functionality has been ignored completely.

Other than that seems to be working fine.

[dimitrovmaksim]

I'm not sure where this comes from. I'm not familiar with timeseries and aggregation entities, which seem to have auto incremented Int8 ids (at least according to the docs)

gnd codegen will produce this for a regular entity from the schema. The comment before the constructor seems incorrect, at least for regular entities. Also I don't think regular entities with and id of type ID or Bytes, should be auto-incremented. Also (2) if (id !== null) <--- this won't work with AS < 0.20.0, before === and == were unified https://github.com/AssemblyScript/assemblyscript/releases/tag/v0.20.0

export class ExampleEntity extends Entity {
  /**
   * Leaving out the id argument uses an autoincrementing id.
   */
  constructor(id: Bytes | null = null) {
    super();
    if (id !== null) {
      this.set("id", Value.fromBytes(id));
    }
  }

  save(): void {
    let id = this.get("id");
    if (id == null || id.kind == ValueKind.NULL) {
      store.set("ExampleEntity", "auto", this);
    } else {
      assert(
        id.kind == ValueKind.BYTES,
        `Entities of type ExampleEntity must have an ID of type Bytes but the id '${id.displayData()}' is of type ${id.displayKind()}`,
      );
      store.set("ExampleEntity", id.toBytes().toHexString(), this);
    }
  }

Also this is what gnd generates for a timeseries Entity

export class Data extends Entity {
  /**
   * Leaving out the id argument uses an autoincrementing id.
   */
  constructor(id: i64 = i64.MIN_VALUE) {
    super();
    if (id != i64.MIN_VALUE) {
      this.set("id", Value.fromI64(id));
    }
  }

  save(): void {
    let id = this.get("id");
    if (id == null || id.kind == ValueKind.NULL) {
      store.set("Data", "auto", this);
    } else {
      assert(
        id.kind == ValueKind.INT8,
        `Entities of type Data must have an ID of type Int8 but the id '${id.displayData()}' is of type ${id.displayKind()}`,
      );
      store.set("Data", id.toI64().toString(), this);
    }
  }
...
}

and this is from graph-cli v0.98.1:

export class Data extends Entity {
  constructor(id: Int8) {
    super();
    this.set("id", Value.fromI64(id));
  }

  save(): void {
    let id = this.get("id");
    assert(id != null, "Cannot save Data entity without an ID");
    if (id) {
      assert(
        id.kind == ValueKind.INT8,
        `Entities of type Data must have an ID of type Int8 but the id '${id.displayData()}' is of type ${id.displayKind()}`,
      );
      store.set("Data", id.toI64().toString(), this);
    }
  }
...
}

I'm a little bit confused here :D Both are specVersion: 1.3.0 and apiVersion: 0.0.9