Automated enforcement of deprecated component removal
automating deprecation governance in CI.
lint rule failing new usages, codemods for existing ones, and a usage dashboard gating removal.
hard-failing builds day one with no migration path.
What's really being asked
The interviewer wants a governance pipeline that scales beyond polite warnings. The hard part is preventing new usage while smoothly retiring existing usage, all without grinding consumer teams to a halt.
The full answer
Layer the enforcement. First, an ESLint rule (or a similar linter for non-JS stacks) detects imports of the deprecated component; configure it as a warning initially, then escalate to an error so CI blocks new pull requests that add usage. Second, ship a codemod, for example a jscodeshift transform, that rewrites existing call sites to the replacement automatically, handling prop renames. Third, feed a central usage dashboard from the static scans so you know who still depends on it. Fourth, gate the actual deletion: only flip the lint rule to a hard org-wide error and remove the component once dashboards show usage near zero, with a published timeline and an escape hatch for genuine blockers.
The mistakes people make
Making the CI gate a blocking error immediately, which breaks unrelated builds and breeds resentment. Providing no automated migration, forcing every team to hand-edit. Enforcing only locally so the rule is easily bypassed.
What usually comes next
How do you handle a team that legitimately cannot migrate in time? How do you prevent developers from disabling the rule? How do codemods handle ambiguous prop mappings?
A concrete example
You publish an ESLint plugin rule no-legacy-card set to warn, plus a codemod npx ds-codemod legacy-card-to-card. CI runs the linter and fails only on newly added usages while existing ones stay as warnings. The adoption dashboard tracks the burndown; when it hits zero, you promote the rule to error everywhere and delete LegacyCard in the next major release.
Interview question
Why escalate a deprecation lint rule from warning to blocking error gradually rather than blocking all builds immediately?
- a.It prevents new usages while giving existing consumers time and tooling to migrateCorrect
- b.ESLint cannot emit errors until it has first emitted warnings
- c.Blocking errors are only supported in CI, not local development
- d.Gradual escalation reduces the size of the compiled bundle
Why? this is the answer
Staged escalation stops new debt immediately while letting teams migrate existing code via codemods, avoiding broken pipelines. The other options misstate how ESLint and bundling work.
Just read this? Test yourself on what you have been reading.
Read the original → opsmx.com
- #design-systems
- #deprecation
- #ci-cd
- #codemods
- #linting
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. Open roles that interview on design-systems — each one lists the topics its interview covers.
See open roles