Allow fetching expected build ID via Ponder CLI util

[tk-o]

Problem / use case

Ponder calculates the build ID for a given app instance by hashing the following values:

• content hash of serialized ponder config object (bound with export default in ponder.config.ts),
• content hash of vite-processed ponder schema (exported members from ponder.schema.ts),
• content hash of all files (raw content) matching src/**/*.{m?ts,m?js}

Then, build ID is used to determine if the current ponder app can even run with declared database schema name value (--schema value passed via CLI arg, or DATABASE_NAME value passed as an env var).

I'd like to be able to derive DATABASE_NAME value from build ID (or it's source: config hash, code hash, schema definition hash). This will allow the indexer operator to not worry about coming up with a next DATABASE_SCHEMA value while iterating on their indexer development.

Proposed solution

Create a CLI options that will return:

• config hash
• source code hash
• schema definition hash
• build ID (the hash of hashes above)

This will enable indexer app operators to reliably set a determiistic auto-generated value as DATABASE_SCHEMA=<value> / --schema <value>.

For example:

ponder start --schema $(ponder build-id)
ponder start --schema $(ponder build-id --config-hash)-$(ponder build-id --source-code-hash)-$(ponder build-id --schema-hash)

[lightwalker-eth]

Taking a step back, our overall goal is to make it easy for others to run their own deployments of ENSNode (built on Ponder) and for everything to "just work".

The key focus here is not developers iterating on indexing code. Instead the key focus is on deployers who just want to deploy a Ponder app that someone else developed.

It's too complicated to expect 3rd party app deployers who need / expect everything to "just work" to manually configure the DATABASE_SCHEMA correctly, especially when they might perform actions like the following across time:

1. Upgrading from version A -> version B of ENSNode.
2. Changing environment variables such as ENS_DEPLOYMENT_CHAIN or ACTIVE_PLUGINS that we use to dynamically generate the appropriate "Ponder Config".

We'd like the ability to define a default / "fallback" DATABASE_SCHEMA for the case that no DATABASE_SCHEMA is explicitly passed via the cli or environment variables.

The most simple solution might be to have an autogenerated default / fallback DATABASE_SCHEMA value that's equal to the autogenerated "Ponder Build Id", such that it would stop being an error if no DATABASE_SCHEMA were explicitly defined.

A more advanced solution might involve a strategy where Ponder allowed a host app to define an optional callback function to generate a default / fallback DATABASE_SCHEMA and for that callback function to receive the "Ponder Build Id" as a param.

If such a callback function existed, it would enable schema names to be generated with more symbolic meaning. That would be nice since whoever is looking through a list of database schemas could more easily understand what each is associated with.

---

The CLI strategy proposed above would also enable a solution, but my bias would be to implement this through an optional callback function (as described above) so that the CLI can stay more simple.