It was the summer of 2023, and at the time, I had not found tooling that was able to tell me component usage throughout our codebase. As a Frontend Platform engineer, I lacked insight into the intricacies of our product (what feature flags and capabilites would we need to turn on to render specific ui's?!). So, we needed a way for teams to be able to scan their code-owned files for component usage so we can help them plan and execute migration.

What We Wanted to Know (Acceptance Criteria)

Where our design system components were being used
What props were being used on those components
What styles were being applied to those components
If I was a product engineer, how do I know the scope of my work

This information could help teams get an idea of the migration complexity, and also inform how we build our new library. At the time, Omlet didn't support this kind of scannning, and neither did react-scanner-- so I ended up building a tool based on react scanner that fit our needs.

A Somewhat Brief Breakdown

Here are the packages I used for this tool:

  "@typescript-eslint/typescript-estree": "^8.53.0",
  "astray": "^1.1.1",
  "chalk": "4.1.1",
  "cli-progress": "^3.12.0",
  "fdir": "^5.2.0",
  "glob": "^13.0.0",
  "google-auth-library": "^9.7.0",
  "googleapis": "^134.0.0",
  "inquirer": "8.2.2",
  "inquirer-fuzzy-path": "2.2.0",
  "typescript": "^5.9.3",

Okay, yes. So there are quite a few AST parsers (babel-parser, babel-eslint, acorn), but we landed on astray/@typescript-eslint/typescript-estree because our in-house component library was built with Typescript, and this parser offers full type aware analysis. As I continued to build, I made use of AST Explorer to help visualize the AST structures. Finding all the instances was certainly tricky, and admittedly my tool is not 100% where I want it to be, but it got the job done for this specific use case.

The tool works by first scanning the file directory for all code owned files (using fdir and glob), then parsing each file with astray/@typescript-eslint/typescript-estree. From there, the AST is traversed to find instances of component usage, props, and styles. The results are then aggregated and presented in a JSON report-- which I later used to generate a Google Sheet for easier consumption by our program manager (using googleapis and google-auth-library).

TO NOTE: In terms of open sourcing this, I am still cleaning this tool up to be used more broadly, as file directories and code ownership regex are currently hardcoded for our specific use case. Stay tuned for updates! I'll add a demo here once it's ready.

What I Would Have Done Today

Today, tooling looks very different. There's opportunity here to leverage Omlet for our initial estimation, and with their VS code plugin, teams can check their component usage as part of their day to day workflow. And even in terms of migrating from Chakra v2 to v3, with Chakra-ui's MCP support, migration from one version to the next can be done with a little more ease.

JULIE WONGBANDUE

Projects