Coexisting major versions during migration

WHAT THIS TESTS This checks whether you understand module resolution, CSS scoping, and the real cost of breaking changes. Protracted migrations are common in large apps, and naive upgrades cause subtle global conflicts.

A GOOD ANSWER COVERS Explain that you can install two majors simultaneously using package aliases (ds-v1 pointing at version one and ds-v2 at version two) or by publishing each major under a distinct package name. Module resolution then keeps the two trees separate so imports are unambiguous. Critically, you must isolate anything global: scope CSS custom properties under different selectors, prefix or hash class names so styles do not bleed, and avoid shared singletons. Migrate incrementally, one route or feature at a time, validating visually as you go. Provide a clear deprecation timeline so the dual-install period ends.

COMMON WRONG ANSWERS Assuming a version bump alone is enough, ignoring that breaking changes are breaking. Forgetting that global CSS resets, font imports, or a shared design token sheet will collide between versions. Overlooking duplicated runtime context, where two copies of a provider mean components read the wrong one.

LIKELY FOLLOW-UPS How do you prevent two copies of React or a context provider from conflicting? How do you keep the visual inconsistency tolerable to users? How do you enforce that the dual period is temporary?

ONE CONCRETE EXAMPLE You alias @ds/core to v1 and @ds/core-next to v2 in package.json, wrap each region of the app in its own themed provider with namespaced token selectors, and migrate the settings area first. The pitfall surfaces immediately: the bundle grows because both component sets ship, and a global font reset from v2 leaks into v1 pages until you scope it. You accept the temporary bloat, fix the global leak, and set a hard removal date for v1.