migrate-component

Migrate component

Migrate the $0 component from $1 to $2.

Step 1: Read the current implementation

Find and read the current $0 component file. Search for it:

• In src/components/, components/, app/components/, or similar common locations
• Using grep -r "$0" --include="*.$1*" -l if the framework extension is known (e.g., .vue, .jsx)

Read all files that make up the component:

• The main component file
• Any associated style files (.css, .scss, .module.css)
• Any associated test files (*.test.*, *.spec.*)

If you cannot find the component, stop and ask the user for the file path.

Step 2: Understand props, state, and behavior

Before writing any code, document:

• All props the component accepts (name, type, default value, whether required)
• All internal state (what it tracks and how it changes)
• All events the component emits or callbacks it invokes
• Side effects (data fetching, subscriptions, DOM manipulation)
• The rendered structure (what it produces visually or structurally)

This documentation becomes the specification the new implementation must satisfy.

Step 3: Write the equivalent in $2

Write the $0 component in $2, matching the same public API:

• Same prop names and types
• Same event names and payloads
• Same rendered structure (or nearest equivalent in $2)
• Same behavior for all documented state transitions

Use idiomatic $2 patterns. Do not transliterate $1 patterns directly into $2 if $2 has a better way to express the same thing.

Step 4: Update tests

Rewrite any tests associated with the original component to use $2 testing conventions:

• Update imports to point to the new component file
• Update any framework-specific test utilities (e.g., mount from $1 to the $2 equivalent)
• Preserve all test cases — every behavior tested in $1 must be tested in $2

Step 5: Report what changed and what needs manual review

Produce a brief report:

Changed:

• List of files created or modified

Preserved:

• Confirmation that all props, events, and behaviors have equivalents

Needs manual review:

• Any behavior that could not be automatically preserved (e.g., a lifecycle hook that has no direct equivalent in $2)
• Any $1-specific third-party libraries used in the original that may not have $2 equivalents
• Performance characteristics that may differ between frameworks

Do not delete the original $1 component file. Leave that for the user to remove after verifying the migration.