First steps to deprecate a legacy component
knowing how to signal deprecation without breaking users.
add a JSDoc @deprecated tag and IDE/console warning, document the migration, and keep the component working.
deleting it immediately.
What's really being asked
The interviewer wants to see whether you understand deprecation as a communication and migration problem, not just a delete operation. Senior engineers signal intent inside the code so consumers discover it where they work.
The full answer
Start by adding a machine-readable signal: a @deprecated JSDoc or TSDoc tag on the component and its exported type, which most editors render with a strikethrough and a tooltip. Add a development-only console warning that fires once, naming the replacement and a doc link, while staying silent in production to avoid noise. Update the documentation site and Storybook to label the component deprecated and link a migration guide. Optionally ship an ESLint rule or codemod so teams get inline nudges and an automated upgrade path. Keep LegacyCard fully functional during the window and announce a target removal version.
The mistakes people make
Deleting the component immediately, which breaks every consumer at once. Only posting in chat, which leaves no durable trace in the code. Logging warnings in production, which floods user consoles and can hurt performance.
What usually comes next
How do you make the warning fire only once? How would you measure remaining usage before removal? When is it safe to actually delete the component, and how does that map to semantic versioning?
A concrete example
You add @deprecated Use Card instead. See /migration/card above the LegacyCard declaration, wrap a useEffect in the component that calls console.warn once per session in non-production builds, publish a minor version, then announce removal in the next major. Editors show the strikethrough, dashboards track adoption, and nothing breaks until the planned major release.
Interview question
Why mark a component @deprecated and warn in dev rather than just deleting it in the same release?
- a.Deleting code is impossible without a major version bump
- b.@deprecated tags improve runtime performance of the new component
- c.Deletion forces an immediate coordinated migration that breaks all consumers at onceCorrect
- d.Console warnings are required by the JavaScript specification
Why? this is the answer
A graceful deprecation lets consumers migrate on their own schedule while the old component keeps working; deleting it immediately breaks every dependent app. The performance and spec claims are unrelated to deprecation.
Just read this? Test yourself on what you have been reading.
Read the original → octopus.design
- #design-systems
- #deprecation
- #component-library
- #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. Open roles that interview on design-systems — each one lists the topics its interview covers.
See open roles