Caveats and known limitations

[razgraf]

Mustache and multi-network

• In order to use the multi-network approach we went with mustache. There is a new multi-network support in the docs but it uses JSON files for configs.
• As JSON files cannot be imported later into Assembly Script (to re-use constants in code as well as in the YAML template)
• Mustache will take the $NETWORK variant given as an argument to the deploy script and prepare a JS file for the YAML template (mustache doesn't work with TS source files) and an env.ts file to be imported in the code

Configuration files

• We use both YAML and YML because the subgraph requires subgraph.yaml. We should test if it works with simple YML type too.

Generated files

• Generated files (by us and by codegen) have been moved together to packages/core/src/generated

Linter

• There is no linter for Assembly Script (at least I couldn't find any, except from a makeshift one from Spotify.

Graph-cli/ts version

• The latest known version of graph-cli (~0.39) doesn't play well with yarn berry. We reverted to an older version for the time being.

Duplicated logic in the create stream handlers

EventCreateLinearStream | EventCreateProStream

While the linear and pro events have a lot of common content, we cannot use type unions in Assembly Script. AS doesn't even seem to allow defining custom types, which makes generics hard. I've also attempted to do it with classes (extending for common params and overriding different behavior) but to no avail.

[PaulRBerg]

I was able to address these limitations in my refactor PR.

• We no longer use Mustache. We programmatically generate the YAML files using js-yaml.
• JSON files cannot be imported in AssemblyScript, yes, but it is possible to provide a context object in each dataSource. I've used this context for declaring the contract version (e.g. v1.0) contract alias (e.g. LL), chain ID, and Lockup addresses (which are needed in the Airdrops subgraph to exclude unofficial deployments of Lockup).
• We no longer use a monorepo. The overhead was not worth it. A single repo has the nice benefit of not having to copy-paste the constants package anymore, alongside a host of other benefits.
• I was able to implement classes for common params.