Design System Migration Codemod <!-- omit in toc -->
This codemod automates the migration of components between design systems. Currently supports migration from Orbiter to Hopper, with extensible architecture for other design system migrations.
Key Features:
- ✅ Automated component migrations - Updates import statements and component names
- ✅ Property transformations - Maps old properties to new equivalents
- ✅ Migration analysis - Generates usage reports and migration guidance
- ✅ Extensible mappings - Support for multiple design system migrations
Table of contents <!-- omit in toc -->
Quick Start
Orbiter to Hopper Migration Example
Before:
tsx
After:
tsx
Usage Examples
The default mapping table is set. for Orbiter to Hopper. If you want to run it for other mappings, you need to set it through the mappings parameter.
Migrate All Components
bash
Migrate by Category
bash
Migrate Specific Components
bash
Target Specific Path
Run the command in the desire path or pass the target path with the -t argument.
bash
Usage Analysis
Generate usage reports to understand your migration scope:
bash
Key Parameters:
| Parameter | Description | Example |
|---|---|---|
| -a <filename> | Output analysis to JSON file | -a usage-report.json |
| -c <components> | Specify components to migrate | -c layout or -c Div,Text |
| -t <path> | Target specific path | -t /app/users |
| --project <name> | Track usage by project/team. It is pretty usefule when you analysis multiple repos and want to aggregate analysis results. | --project frontend-team |
| --mappings <type> | Specify mapping table (orbiter-to-hopper (default) or hopper) | --mappings hopper |
| --deep true | Include file locations | --deep true |
| --filter-unmapped <type> | Show only unmapped items | --filter-unmapped props |
| -n 1 | Use single thread (required for analysis) | -n 1 |
Sample Analysis Output:
json
Contributing
To add support for other design system migrations or contribute to existing ones, see CONTRIBUTING.md for detailed guidelines.