Automated detection of deprecated component usage

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.