|
| 1 | +# Migration Strategy: Inertia Rails → Shakapacker + React on Rails |
| 2 | + |
| 3 | +## Repository Setup |
| 4 | + |
| 5 | +### Fork & Clone |
| 6 | +```bash |
| 7 | +# Fork the official repository |
| 8 | +gh repo fork inertia-rails/react-starter-kit --clone --remote-name upstream |
| 9 | + |
| 10 | +# Or if you want it in a specific location |
| 11 | +cd ~/projects # or wherever you keep projects |
| 12 | +gh repo fork inertia-rails/react-starter-kit --clone |
| 13 | +cd react-starter-kit |
| 14 | +``` |
| 15 | + |
| 16 | +## PR Strategy: Incremental Migration |
| 17 | + |
| 18 | +### Phase 1: Foundation PRs (Non-Breaking) |
| 19 | + |
| 20 | +#### PR #1: Add Shakapacker alongside Vite |
| 21 | +**Branch:** `add-shakapacker-support` |
| 22 | +**Changes:** |
| 23 | +- Add `shakapacker` gem (keep `vite_rails`) |
| 24 | +- Add webpack configuration files |
| 25 | +- Update package.json with webpack dependencies |
| 26 | +- Keep both build systems working |
| 27 | +**Why:** Allows testing without breaking existing setup |
| 28 | + |
| 29 | +#### PR #2: Prepare for React on Rails |
| 30 | +**Branch:** `prepare-react-on-rails-structure` |
| 31 | +**Changes:** |
| 32 | +- Reorganize `app/frontend` → `app/javascript` (symlink for compatibility) |
| 33 | +- Add bundles directory structure |
| 34 | +- Update import paths to be flexible |
| 35 | +- Add `.babelrc` and webpack configs |
| 36 | +**Why:** Sets up structure without breaking Inertia |
| 37 | + |
| 38 | +#### PR #3: Add React on Rails gem |
| 39 | +**Branch:** `add-react-on-rails-gem` |
| 40 | +**Changes:** |
| 41 | +- Add `react_on_rails` gem |
| 42 | +- Add initializer (disabled by default) |
| 43 | +- Add helper methods to ApplicationController |
| 44 | +- Documentation for enabling |
| 45 | +**Why:** Makes gem available without forcing usage |
| 46 | + |
| 47 | +### Phase 2: Parallel Implementation PRs |
| 48 | + |
| 49 | +#### PR #4: Dual-mode components |
| 50 | +**Branch:** `dual-mode-components` |
| 51 | +**Changes:** |
| 52 | +- Create React on Rails versions of components |
| 53 | +- Add registration scripts |
| 54 | +- Keep Inertia components unchanged |
| 55 | +- Add environment variable to switch modes |
| 56 | +**Why:** Allows A/B testing both approaches |
| 57 | + |
| 58 | +#### PR #5: View templates |
| 59 | +**Branch:** `add-view-templates` |
| 60 | +**Changes:** |
| 61 | +- Create `.html.erb` files for each route |
| 62 | +- Use conditional rendering (Inertia vs React on Rails) |
| 63 | +- Add layout files |
| 64 | +- Keep controllers unchanged |
| 65 | +**Why:** Prepares view layer without breaking Inertia |
| 66 | + |
| 67 | +#### PR #6: SSR implementation |
| 68 | +**Branch:** `implement-ssr` |
| 69 | +**Changes:** |
| 70 | +- Add server bundle configuration |
| 71 | +- Configure SSR for React on Rails |
| 72 | +- Add prerender options |
| 73 | +- Performance benchmarks |
| 74 | +**Why:** Shows SSR benefits |
| 75 | + |
| 76 | +### Phase 3: Migration Tooling PRs |
| 77 | + |
| 78 | +#### PR #7: Migration script |
| 79 | +**Branch:** `add-migration-script` |
| 80 | +**Changes:** |
| 81 | +```ruby |
| 82 | +# lib/tasks/migrate_to_react_on_rails.rake |
| 83 | +namespace :react_on_rails do |
| 84 | + desc "Migrate from Inertia to React on Rails" |
| 85 | + task :migrate => :environment do |
| 86 | + # Automated migration tasks |
| 87 | + end |
| 88 | +end |
| 89 | +``` |
| 90 | +**Why:** Helps users migrate easily |
| 91 | + |
| 92 | +#### PR #8: Feature flags |
| 93 | +**Branch:** `add-feature-flags` |
| 94 | +**Changes:** |
| 95 | +- Add config flags to switch between Inertia/React on Rails |
| 96 | +- Environment-based configuration |
| 97 | +- Documentation |
| 98 | +**Why:** Allows gradual rollout |
| 99 | + |
| 100 | +### Phase 4: Optimization PRs |
| 101 | + |
| 102 | +#### PR #9: Replace Vite with Shakapacker |
| 103 | +**Branch:** `shakapacker-primary` |
| 104 | +**Changes:** |
| 105 | +- Make Shakapacker the default |
| 106 | +- Move Vite to optional |
| 107 | +- Update development scripts |
| 108 | +- Update deployment configs |
| 109 | +**Why:** Better Rails integration |
| 110 | + |
| 111 | +#### PR #10: Performance optimizations |
| 112 | +**Branch:** `performance-optimizations` |
| 113 | +**Changes:** |
| 114 | +- Code splitting configuration |
| 115 | +- Caching strategies |
| 116 | +- Bundle optimization |
| 117 | +- CDN setup |
| 118 | +**Why:** Production readiness |
| 119 | + |
| 120 | +### Phase 5: Future RSC Preparation |
| 121 | + |
| 122 | +#### PR #11: RSC-ready architecture |
| 123 | +**Branch:** `rsc-preparation` |
| 124 | +**Changes:** |
| 125 | +- Add 'use client' directives where appropriate |
| 126 | +- Separate server/client components |
| 127 | +- Document RSC upgrade path |
| 128 | +- Add Pro version detection |
| 129 | +**Why:** Future-proofing |
| 130 | + |
| 131 | +## File Structure Evolution |
| 132 | + |
| 133 | +``` |
| 134 | +react-starter-kit/ |
| 135 | +├── app/ |
| 136 | +│ ├── frontend/ # Original (Phase 1) |
| 137 | +│ ├── javascript/ # New (Phase 2+) |
| 138 | +│ │ ├── bundles/ # React on Rails components |
| 139 | +│ │ ├── packs/ # Entry points |
| 140 | +│ │ └── components/ # Shared components |
| 141 | +│ └── views/ |
| 142 | +│ └── [controllers]/ # New view templates |
| 143 | +├── config/ |
| 144 | +│ ├── inertia_rails.rb # Keep |
| 145 | +│ ├── react_on_rails.rb # Add |
| 146 | +│ ├── shakapacker.yml # Add |
| 147 | +│ └── vite.json # Keep initially |
| 148 | +└── package.json # Both dependencies |
| 149 | +``` |
| 150 | + |
| 151 | +## PR Guidelines |
| 152 | + |
| 153 | +### Each PR Should: |
| 154 | +1. **Be focused**: One feature/change per PR |
| 155 | +2. **Be backward compatible**: Don't break existing functionality |
| 156 | +3. **Include tests**: Add specs for new features |
| 157 | +4. **Have documentation**: Update README with migration notes |
| 158 | +5. **Show benchmarks**: Performance comparisons where relevant |
| 159 | + |
| 160 | +### Commit Message Format |
| 161 | +``` |
| 162 | +feat(shakapacker): Add Shakapacker alongside Vite |
| 163 | +
|
| 164 | +- Add shakapacker gem to Gemfile |
| 165 | +- Configure webpack for development/production |
| 166 | +- Update bin scripts for dual-mode operation |
| 167 | +- Keep Vite as default, Shakapacker as opt-in |
| 168 | +
|
| 169 | +BREAKING CHANGE: None |
| 170 | +Migration: Set USE_SHAKAPACKER=true to test |
| 171 | +``` |
| 172 | + |
| 173 | +## Timeline Estimate |
| 174 | + |
| 175 | +| Phase | PRs | Time | Notes | |
| 176 | +|-------|-----|------|-------| |
| 177 | +| Phase 1 | PR 1-3 | Week 1 | Foundation, non-breaking | |
| 178 | +| Phase 2 | PR 4-6 | Week 2 | Parallel implementation | |
| 179 | +| Phase 3 | PR 7-8 | Week 3 | Migration tooling | |
| 180 | +| Phase 4 | PR 9-10 | Week 4 | Optimization | |
| 181 | +| Phase 5 | PR 11 | Week 5 | Future preparation | |
| 182 | + |
| 183 | +## Benefits of This Approach |
| 184 | + |
| 185 | +1. **Non-breaking**: Users can adopt gradually |
| 186 | +2. **Testable**: Each PR can be tested independently |
| 187 | +3. **Reversible**: Can roll back if issues arise |
| 188 | +4. **Educational**: Community learns by following PRs |
| 189 | +5. **Collaborative**: Others can contribute to specific PRs |
| 190 | + |
| 191 | +## Quick Start Commands |
| 192 | + |
| 193 | +```bash |
| 194 | +# Fork and setup |
| 195 | +gh repo fork inertia-rails/react-starter-kit --clone |
| 196 | +cd react-starter-kit |
| 197 | + |
| 198 | +# Create first PR branch |
| 199 | +git checkout -b add-shakapacker-support |
| 200 | + |
| 201 | +# Install dependencies |
| 202 | +bundle add shakapacker --group "development, production" |
| 203 | +bundle install |
| 204 | + |
| 205 | +# Generate Shakapacker config |
| 206 | +bundle exec rails shakapacker:install |
| 207 | + |
| 208 | +# Create PR |
| 209 | +gh pr create --title "Add Shakapacker support alongside Vite" \ |
| 210 | + --body "First step in migration to React on Rails" |
| 211 | +``` |
| 212 | + |
| 213 | +## Communication Strategy |
| 214 | + |
| 215 | +### PR Description Template |
| 216 | +```markdown |
| 217 | +## What does this PR do? |
| 218 | +[Describe the changes] |
| 219 | + |
| 220 | +## Why is this change needed? |
| 221 | +[Explain the benefits] |
| 222 | + |
| 223 | +## How to test? |
| 224 | +1. [Step by step instructions] |
| 225 | +2. [Expected results] |
| 226 | + |
| 227 | +## Migration impact |
| 228 | +- [ ] Breaking change |
| 229 | +- [ ] Requires migration |
| 230 | +- [ ] Documentation updated |
| 231 | + |
| 232 | +## Performance |
| 233 | +| Metric | Before | After | |
| 234 | +|--------|--------|-------| |
| 235 | +| Build time | X | Y | |
| 236 | + |
| 237 | +## Related issues |
| 238 | +Refs #[issue number] |
| 239 | +``` |
| 240 | + |
| 241 | +## Next Steps |
| 242 | + |
| 243 | +1. **Fork the repository** (outside demos folder) |
| 244 | +2. **Create first PR** (Shakapacker support) |
| 245 | +3. **Open discussion issue** explaining migration plan |
| 246 | +4. **Engage community** for feedback |
| 247 | +5. **Iterate based on feedback** |
| 248 | + |
| 249 | +This incremental approach ensures: |
| 250 | +- Community buy-in |
| 251 | +- Gradual adoption |
| 252 | +- Learning opportunity |
| 253 | +- Maintained stability |
| 254 | +- Clear upgrade path to Pro features later |
0 commit comments