Designing a component deprecation process
Whether you can retire a component without breaking consumers.
Announce with a replacement and timeline, mark deprecated with runtime and lint warnings, provide codemods, then remove only in a major release.
What's really being asked
The interviewer wants a humane, staged deprecation that respects consumers. They are listening for both technical signals and communication, plus a no-surprise removal policy tied to versioning.
The full answer
Deprecation is a process, not a delete. First, decide and announce: publish the rationale, name the replacement, and set a removal timeline. Mark it technically while keeping it functional: add JSDoc deprecated annotations so IDEs flag it, emit a one-time console warning in development, add a lint rule that flags new usage, and put a banner on the docs page. Provide a migration path: a step-by-step guide and, where possible, an automated codemod that rewrites usages. Track remaining usage across consuming repos so you know who still depends on it. Communicate repeatedly through changelogs, release notes, and direct outreach to heavy users. Remove the component only in a major version once usage has dropped to near zero, never in a minor or patch.
The mistakes people make
Deleting the component immediately, breaking every consumer. Marking it deprecated but giving no replacement or migration tooling. Removing it in a minor release, violating SemVer. Announcing once and assuming everyone saw it.
What usually comes next
How do you handle teams that ignore the warnings? How do you measure remaining usage? When is it safe to actually remove?
A concrete example
You deprecate the old Modal in favor of Dialog. v3.2 adds a deprecated tag, a dev console warning, and a lint rule; you ship a codemod and a guide, and track that twenty repos still import Modal. Over two quarters usage drops to two repos; you help them migrate, then remove Modal in v4.0 with the breaking change documented.
Interview question
In which release type is it appropriate to actually remove a deprecated component, per SemVer norms?
- a.A patch release, since removal fixes maintenance burden
- b.A major release, only after usage of the replacement is highCorrect
- c.Any release, as long as a console warning was shown once
- d.A minor release, since a replacement already exists
Why? this is the answer
Removal is a breaking change, so it belongs in a major release and only after migration is largely complete. Patch and minor releases must not break consumers, so removing a component in either violates SemVer.
Just read this? Test yourself on what you have been reading.
Read the original → octopus.design
- #design-systems
- #deprecation
- #migration
- #versioning
- #codemods
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