WORK STORY / 01
Use AST analysis to calculate change impact across a multi-brand system
Context
The same codebase was overridden, composed, and dynamically loaded for different brands. After a shared file changed, the actual impact could extend beyond a component to a set of real URLs hidden behind different brand settings, routers, and runtime configurations. At the time, engineers largely determined this impact manually, while QA relied on prior experience to choose regression scope. I believed the real problem was not simply who imported a file, but the information gap between code dependencies and the routes users actually entered.
My Decision & Action
I reframed the problem as dependency tracing. I first used ts-morph to parse imports, aliases, and routers and build static dependency relationships. A vite-node sandbox then loaded each brand’s runtime configuration to supply composition information that AST analysis alone could not know. Finally, I traced references upward from the target file, translating code dependencies into the brands, routes, and actual URLs affected by the change.
Outcome
The tool could output the actual affected URLs for each brand from a specified file, allowing frontend engineers and QA to determine test scope from the same information rather than relying entirely on manual inventories and individual memory. For me, this did more than save lookup time: it turned system knowledge formerly held in engineers’ heads into a result software could repeatedly calculate.
Reflection
This made me wary of system knowledge that only senior engineers could remember. When a project is so complex that experience is needed to answer where changing a file will have an effect, the problem is not only inadequate documentation; an important system relationship has not yet been modeled. If information can be derived programmatically, I prefer tools to calculate it rather than requiring people to keep the entire system in their heads.