Creating 1155 Watcher - inputConfig.contracts.map is not a function

[lanceseidman]

Here is my config file:

# Example config.yaml
# Contracts to watch (required).
# Can pass empty array ([]) when using subgraphPath.
contracts:
    # Contract name.
    name: BoredApeYachtClub
    # Contract file path or an url.
    path: ./BAYC.sol
    # Contract kind (should match that in {subgraphPath}/subgraph.yaml if subgraphPath provided)
    kind: Empty

# Output folder path (logs output using `stdout` if not provided).
outputFolder: ../bayc-watcher

# Code generation mode [eth_call | storage | all | none] (default: none).
mode: eth_call

# Kind of watcher [lazy | active] (default: active).
kind: active

# Watcher server port (default: 3008).
port: 3008

# Flatten the input contract file(s) [true | false] (default: true).
flatten: false

# Path to the subgraph build (optional).
# Can set empty contracts array when using subgraphPath.
subgraphPath: ([]) #../graph-node/test/subgraph/example1/build

# NOTE: When passed an *URL* as contract path, it is assumed that it points to an already flattened contract file.

I have made the folder in the folder above (mkdir ../bayc-watcher) and the BAYC.sol file is in the same folder as the config. To see the BAYC contract file (flattened), visit: https://etherscan.io/address/0xbc4ca0eda7647a8ab7c2061c2e118a18a936f13d#code#L1.

The error when trying to run with the config is as follows:

yarn codegen --config-file ./config.yaml 
yarn run v1.22.19
$ ts-node src/generate-code.ts --config-file ./config.yaml
TypeError: inputConfig.contracts.map is not a function
    at getConfig (/home/lance/Projects/AF/watcher-ts/packages/codegen/src/generate-code.ts:348:43)
    at /home/lance/Projects/AF/watcher-ts/packages/codegen/src/generate-code.ts:51:18
    at step (/home/lance/Projects/AF/watcher-ts/packages/codegen/src/generate-code.ts:36:23)
    at Object.next (/home/lance/Projects/AF/watcher-ts/packages/codegen/src/generate-code.ts:17:53)
    at fulfilled (/home/lance/Projects/AF/watcher-ts/packages/codegen/src/generate-code.ts:8:58)
Done in 9.97s.

[prathamesh0]

@lanceseidman

The error when trying to run with the config is as follows:

The above error is thrown because of a missing - in the contracts field of the config.
After making a couple of minor fixes in PR, I was able to generate a watcher for given contract.

The config used:

contracts:
  - name: BoredApeYachtClub
    path: ./BAYC.sol
    kind: Empty

outputFolder: ../bayc-watcher

mode: eth_call

kind: active

port: 3008

flatten: false

subgraphPath:

Note: The contract restricts the Solidity version between [0.6.0, 0.8.0) and the code generator is currently using solc compiler version 0.8.13. So as a temporary fix to generate watcher for this contract, change the solc version in package.json to 0.7.6 and run yarn once before running the codegen command.

---

I have made the folder in the folder above (mkdir ../bayc-watcher) and the BAYC.sol file is in the same folder as the config.

You don't need to manually create the watcher folder, code generator does it for you.

---

I ran the generated watcher as a lazy (server.kind in watcher config) watcher and tested the following GQL request:

{
  ownerOf (
    blockHash: "0x28a6b3bd45f458ffde5f8c41cf972afb045860e5e43e5828c94d8b8957e9616a"
    contractAddress: "0xBC4CA0EdA7647A8aB7C2061c2E118A18a936f13D"
    tokenId: 9353
  ) {
    value
  }
}

Response:

{
  "data": {
    "ownerOf": {
      "value": "0x8fB24403431734258594ec770ACAe83e9283459d"
    }
  }
}

[rickmanelius]

Hi @prathamesh0. Thank you for the PR and all the detail on how to get the BAYC watcher to a completion point.

The next, broader question I have is with respect to the dependency management issue. As I understand it, we have a divergence in this repo's codegen code versus the BAYC solidity files (because their libraries are pinned to a specific range).

If we fast forward 5+ years from now, this type of problem will become more and more prevalent. Watcher data will need to address many historic contracts, but the watcher codebase will continue to evolve. Manually moving the dependency version numbers is both manual and will create breaking changes versus the evolving codebase.

Overarching strategies would be:

1. Modify the codegen's dependencies to match the older solidity file (manual, problematic)
2. Match the historical version of codegen to that of the solidity file (annoying, but still automatable)

To proceed with option 2, we would need to be stricter in our codegen/package.json and yarn.lock file to not allow minor or major increments, and instead only allow patch upgrades. So we would want to use ~ vs ^.

Then we would need to have some form of detector that would default to using the latest version of codegen, but flagging projects that were too old and recommending a tagged version that meets the range within the solidity file.

I suggest we do this in three phases:

1. Create stricter codegen/package.json
2. Do an analysis of the top 50 NFT contracts to determine if this is a consistent issue
3. If it's consistent issue, create a script that acts as a checker/recommender

I'm happy to take on item 2.

[AFDudley]

We don't need to do any of this. It's just a solc tooling issue... there are several ways to address these Ethereum tooling problems, I think talking about 5 years from now is way out of scope. When we have random people using the SDK, we'll solve this issue by integrating with https://github.com/foundry-rs/foundry, https://github.com/ApeWorX/ape, https://github.com/NomicFoundation/hardhat, etc. We don't even have an SDK at the moment.

[zramsay]

resolved