feat(chains): support paths to spec-files to enable permissionless adding of new chains

[mds1]

The current plan is to first add the complete set of data for the 3 initial chains. From there, I'd like to add a helper method that makes it easy to add a new chain based off an existing chain, so the diffs for new chains can be small.

With both of those in place, we can support a feature that lets chains permissionlessly add their own data using e.g. a JSON file that has the same structure as the Chain type in src/types/chains.ts. Assuming we go the JSON route, we'd probably want to use JSON Schema to strongly type it and so users can validate their implementations. There are at least two actively maintained packages that support converting TS types to JSON Schema which would help the conversion:

• https://github.com/YousefED/typescript-json-schema#readme
• https://github.com/vega/ts-json-schema-generator

A chain could define their JSON file and host it somewhere, then users can navigate directly to https://www.evmdiff.com/diff?base=1&target=encodedUrlToChainDiffFile. This would compare chain ID 1 (mainnet) to the chain whose path is specified in the URL.

We'll also have to show a warning that the data is unverified and may not be accurate.

Some chains may be limited by the shape of the Chains type depending on how EVM-(in)compatible they are. One way to mitigate this is to add a generic catch-call section to the end that supports arbitrary keys and values, which get rendered in their own section of the UI.

h/t @alcuadrado for the idea

[MOZGIII]

You could just use zod - it is excellent for this sort of thing. https://github.com/colinhacks/zod

Define the schema in a concise and safe TypeScript and use that at runtime, and optionally export JSON Schema to add to the registries for better authoring experience (i.e. editor completions and etc) for the files.

The only (maybe) downside is you'd have to derive the Chain TypeScript type from the zod schema - this might seem odd and look convoluted, but it is actually a good practice.

[mds1]

I've heard good things about zod but never looked much into it. I see in the docs the .describe method which is used by the zod-to-json-schema package—is this what you're suggesting here, i.e. redefine all types with zod and use describe to add descriptions, then use that package to convert it to a JSON schema? That sounds that a pretty good approach, would love to hear any more thoughts you have or tradeoffs you're aware of here

[MOZGIII]

I've heard good things about zod but never looked much into it. I see in the docs the .describe method which is used by the zod-to-json-schema package—is this what you're suggesting here, i.e. redefine all types with zod and use describe to add descriptions, then use that package to convert it to a JSON schema? That sounds that a pretty good approach, would love to hear any more thoughts you have or tradeoffs you're aware of here

Not all types of course, just the ones that describe the data. Also, zod-to-json-schema is just one of the options afaik, there should be other ways to export zod definitions into a JSON schema.

I mostly use zod for proper validation of types that come from fetch and similar places. With zod, you can use proper types: make await fetchResponse.json() unknown and then explicitly validate/typeguard the received value via zod. I think this is a primary use case. Also, https://github.com/ecyrbe/zodios exists.

[mds1]

Closing this issue as part of the move to automated data collection in https://github.com/mds1/evm-diff/pull/62, since the new design is much more scalable and does not require chains to maintain their own JSON data files