I ran into this while reviewing a PR and wanted to check how others approach it.

The PR was refactoring a shared component in our monorepo to align with an updated design system. As part of that, some variant names needed to be renamed (e.g. updating existing variant values to match new design tokens).

This meant updating usage across a large number of files. The change at each call site was simple and mechanical (just switching to the new variant names, e.g. error → danger), but it touched a lot of places.

As part of the review, there were two possible approaches:

1. Apply the change directly everywhere

• Many small, explicit updates across the codebase (rename at each usage)
• Each change is trivial and easy to review in isolation
• No additional logic introduced
• End state is clean and fully aligned with the design system

2. Introduce compatibility/abstraction to reduce file changes

• Fewer files touched in the PR
• Keep supporting the old variant names
• Add mapping logic inside the component (e.g. mapping old variants to new ones)
• Additional conditionals/tests to support both old and new APIs
• Defers full migration to follow-up work
• Introduces indirection where the value passed at the call site isn’t the value actually used internally

My instinct during the review was to push for (1), even if it means a large file count, because:

• reviewing many simple, obvious changes feels easier than understanding new abstraction/mapping logic
• it avoids introducing temporary complexity into a core shared component
• it ensures we fully migrate to the new design system immediately
• it doesn’t rely on follow-up PRs that may or may not happen
• The migration is type-safe and self-validating. Any missed updates are surfaced by TypeScript at compile time

A counterpoint raised was that it would cause a large file count (around 200 extra files) in the repo. While this is true, they're all one line (one word really) changes that can easily be checked off as 'viewed' whereas the alternative was adding more lines of code, whereas the alternative was adding more lines of code that increase cognitive overhead and require deeper validation than straightforward, mechanical changes.

Curious how others think about this in a review context:

• Do you optimise for fewer files changed, or for lower per-change complexity?
• Where do you draw the line between acceptable duplication vs introducing abstraction?
• Are temporary compatibility layers in shared components worth it, or do they tend to stick around and become tech debt?

Interested in how this is handled on other teams/codebases.