Automated detection of deprecated component usage
Deprecation auditing pipeline.
Machine-readable deprecation metadata, AST scanning across repos, scheduled jobs, per-team dashboards and PR-level warnings with codemod links.
WHAT THIS TESTS Whether you can architect a reliable, automated audit and, crucially, close the loop by making findings actionable for the teams that own the code.
A GOOD ANSWER COVERS Source of truth first: encode deprecations as machine-readable metadata in the library, for example a manifest mapping deprecated components and props to their replacements and codemods, generated from the same JSDoc deprecated tags used in code. Build a scanner using a TypeScript or Babel AST parser so detection is precise, matching imports from the design system and specific deprecated props rather than naive text matching. Run it on a schedule across all consuming repos via CI or a central job, with results written to a datastore. Presentation closes the loop: a dashboard with per-team and per-component counts and trends, scorecards, and proactive automated PR comments or bot-filed issues that link the exact migration guide and codemod command. Prioritize by severity, surfacing accessibility-related deprecations first.
COMMON WRONG ANSWERS Grepping for component names as strings, which misfires on comments, similarly named local components, and re-exports. No machine-readable deprecation source, so the audit drifts from reality. Generating a giant report with no ownership or routing to teams. No link to the fix, leaving teams stuck. Treating all deprecations as equal priority.
LIKELY FOLLOW-UPS Why is AST analysis better than grep here? How do you generate deprecation metadata from code? How do you handle re-exported or aliased imports? How do you avoid alert fatigue and route findings to owners?
ONE CONCRETE EXAMPLE The library emits a deprecations.json from its JSDoc tags. A nightly job AST-scans each repo, finds twelve usages of the deprecated size prop on Button, writes them to the datastore, updates the team's dashboard card, and opens a PR comment on the next change to that file linking the codemod that migrates size to a token-based prop.
Interview question
Why prefer AST-based scanning over a text search when detecting deprecated component and prop usage across repos?
- a.Text search always misses every occurrence of a deprecated prop
- b.Text search cannot read files inside a CI pipeline
- c.AST matching distinguishes real imported usage from comments, aliases, and lookalike namesCorrect
- d.AST parsing is the only way to read TypeScript source files
Why? this is the answer
AST analysis understands code structure, so it resolves imports and props precisely and avoids false positives from comments or similarly named locals. Text search runs fine in CI but produces noisy, unreliable matches.
Just read this? Test yourself on what you have been reading.
- #deprecation
- #ast
- #auditing
- #tooling
- #developer-experience
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles