fix(ensindexer): use lazy-loaded config

[tk-o]

It's best to review this PR with Hide whitespace turned on.

This change prevents premature execution of plugin-specific config factories.

Before this change, running ENSIndexer service with ENS_DEPLOYMENT_CHAIN env var set to other valid value than mainnet would cause application runtime error. The problem was caused due to all plugin config files being unconditionally executed from ponder.config.ts file. For example, the basenames plugin would not find a required datasource loaded when ENS_DEPLOYMENT_CHAIN was set to either sepolia, holesky, or ens-test-env.

ensindexer  | 9:08:53 AM ERROR build      Error while executing 'ponder.config.ts':
ensindexer  | TypeError: Cannot destructure property 'chain' of 'deployment[__vite_ssr_import_3__.DatasourceName.Basenames]' as it is undefined.
ensindexer  |     at /app/apps/ensindexer/src/plugins/basenames/basenames.plugin.ts:24:9
ensindexer  |   22 | // extract the chain and contract configs for Basenames Datasource in order to build ponder config
ensindexer  |   23 | const deployment = getENSDeployment(appConfig.ensDeploymentChain);
ensindexer  | > 24 | const { chain, contracts } = deployment[DatasourceName.Basenames];
ensindexer  |      |         ^
ensindexer  |   25 |
ensindexer  |   26 | export const config = createConfig({
ensindexer  |   27 |   networks: networksConfigForChain(chain.id),
ensindexer  | 9:08:53 AM WARN  process    Failed intial build, starting shutdown sequence
Cleaning up...
 ELIFECYCLE  Command failed with exit code 1.

The fix was to make the plugin config object construction logic lazy-evaluated and only called during plugin activation phase (by when all required datasources must be available).

[changeset-bot]

🦋 Changeset detected

Latest commit: 1f9d3e7

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 10 packages

Name	Type
ensindexer	Patch
ensadmin	Patch
ensrainbow	Patch
@ensnode/ens-deployments	Patch
@ensnode/utils	Patch
@ensnode/ensrainbow-sdk	Patch
@ensnode/ponder-metadata	Patch
@ensnode/ensnode-schema	Patch
@ensnode/ponder-subgraph	Patch
@ensnode/shared-configs	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
admin.ensnode.io	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	May 26, 2025 5:20pm
ensnode.io	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	May 26, 2025 5:20pm
ensrainbow.io	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	May 26, 2025 5:20pm

[shrugs]

perhaps we can restructure to something more like this:

export default {
  get config () {
    // ...
    return createConfig()
  }
  activate: activateHandlers({ ... });
}

so we're exporting a single plugin-shaped object from each plugin file

---

the solution i had in my l2 primary name branch was similar to the previous behavior where we merged the configs

export const getENSDeployment = (ensDeploymentChain: keyof typeof ENSDeployments) =>
  ({
    ...ENSDeployments.mainnet,
    ...ENSDeployments[ensDeploymentChain],
  }) as ENSDeploymentGlobalType;

but i think i prefer your deferred execution approach rather than the hacky merged deployment thing

[tk-o]

A single object describes the public API of a plugin now. Importing default into named const.