"How would you roll out a breaking change to twenty apps?" is the most reliable senior question in a tooling interview, because the answer reveals whether you have ever had consumers. The short version: you do not ship a breaking change, you run a migration.

Know — what counts as breaking

For a layer: renaming or removing a component, composable or util; removing or renaming an app.config key, or changing a default in a way that alters rendering; removing or renaming a runtimeConfig key; removing a page, route or layout; removing a module from the preset that apps relied on; raising the minimum Nuxt version; changing the shape of a type consumers extend.

For a module: renaming or removing an option; changing a default; removing an injected runtime API, hook or alias; raising the minimum Nuxt version; changing the emitted types in a way that fails nuxt typecheck in consuming apps.

Not breaking (but still worth a changelog line): adding an optional option, adding a component with a new prefixed name, adding a hook, widening a type.

Know — the sequence

1. Decide with data. The adoption report says who uses the thing. If one app uses it, talk to that team instead of running a process.
2. Deprecate in a minor. The old name keeps working, delegates to the new one, and warns in development only with a message that names the replacement and links the migration note.
3. Write the migration note before the code. Consumer's point of view: what to change, what it looks like before and after, what breaks if they do nothing, and by when.
4. Codemod when a rename touches many files. A short jscodeshift or regex script in the repository beats twenty teams doing the same edit by hand, and it turns a two-hour task into a reviewed pull request.
5. Canary one app. Usually the platform team's own. Then a second, unrelated one.
6. Announce with a support window. "Old name warns in 2.4, removed in 3.0, which we expect in Q1; we support 2.x until then."
7. Remove in a major, once adoption data shows nobody is on the old path. If someone still is, the deadline was aspirational, not real.

How it works

The deprecation shim for a renamed layer component:

<script setup lang="ts">
// Deprecated in 2.4, removed in 3.0. Use <TeamButton variant="primary">.
import TeamButton from './Button.vue'

// Dev-only: never add console noise to a consumer's production build.
if (import.meta.dev) {
  console.warn('[nuxt-layer-base] <TeamPrimaryButton> is deprecated and will be removed in 3.0. Use <TeamButton variant="primary">. Migration: https://git.internal/layers/base/MIGRATION.md#2-4')
}
</script>

<template>
  <TeamButton variant="primary" v-bind="$attrs">
    <slot />
  </TeamButton>
</template>

The equivalent for a renamed module option, which must keep working and keep type-checking:

import { defineNuxtModule, useLogger } from '@nuxt/kit'

export interface ModuleOptions {
  /** @deprecated since 2.4, use `analytics.enabled`. Removed in 3.0. */
  trackingEnabled?: boolean
  analytics: { enabled: boolean }
}

export default defineNuxtModule<ModuleOptions>({
  meta: { name: 'nuxt-team-toolkit', configKey: 'toolkit' },
  defaults: { analytics: { enabled: false } },
  setup(options) {
    const logger = useLogger('toolkit')
    if (options.trackingEnabled !== undefined) {
      logger.warn('`toolkit.trackingEnabled` is deprecated and will be removed in 3.0; use `toolkit.analytics.enabled`.')
      // Old option still wins if the new one was not set, so nobody breaks today.
      options.analytics.enabled ??= options.trackingEnabled
    }
  },
})

The migration note consumers actually read:

## 2.4 → 3.0

### `<TeamPrimaryButton>` removed
**Why** — one button component with a `variant` prop instead of five near-duplicates.
**Do** — replace `<TeamPrimaryButton>` with `<TeamButton variant="primary">`.
**Codemod** — `npx @team/layer-codemods primary-button .` (reviews as a normal PR).
**If you do nothing** — the component is gone in 3.0 and the build fails with "Failed to resolve component".
**Deadline** — 3.0 ships in Q1; 2.x is supported until then.

Exercise

Be able to say