Use AST analysis to eliminate duplicate schema maintenance in a config-driven framework

Context

When I joined Gorilla, the company already had a config-driven no-code framework.

Users could select React components and adjust props and layouts through the platform, after which a renderer dynamically generated pages from the configuration.

There was, however, a maintenance problem:

Although each component already had prop definitions, the platform also required a separately maintained JSON Schema to know which settings the editor should provide.

Whenever a component was added or changed, engineers therefore had to update the corresponding schema in addition to the code.

As the number of components grew, forgetting to update either definition could make the platform editor’s capabilities inconsistent with the actual component.

My Decision & Action

I believed this problem should not be solved by asking engineers to remember to synchronize two files.

A component’s props already described the capabilities it actually supported, so the other schema should be derived from the code instead of being defined manually again.

I therefore used AST analysis and ts-morph to parse React component prop definitions during the build, automatically extracting and generating the JSON Schema required by the platform.

Originally:

Component Props → Manually maintained JSON Schema → Editor

Changed to:

Component Props → AST parsing → Automatically generated JSON Schema → Editor

The framework’s original config-driven model did not need to be replaced; only the manual maintenance step most likely to fall out of sync was removed.

Outcome

When adding or changing a component, engineers no longer had to maintain another schema definition in parallel.

The structure used by the platform editor could evolve directly with the actual code, also making it easier for the existing no-code framework to keep adding new component capabilities.

Reflection

This later became a judgment I used frequently:

If two pieces of information describe the same thing and one can be reliably derived from the other, people should not be required to maintain both.

What most often becomes unmanageable is not the complexity of the code itself, but the presence of too many copies that are theoretically supposed to remain consistent.