dual-edition-module-migration

Migrate shared modules to mirrored enterprise overlays under enterprise/src/opensource.

5.0k|548|Updated May 14, 2025
One-click install
npx skills add https://github.com/dtyq/magic --skill dual-edition-module-migration
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: dual-edition-module-migration
Source: https://github.com/dtyq/magic/tree/main/frontend/magic-web/.agents/skills/dual-edition-module-migration
Command: npx skills add https://github.com/dtyq/magic --skill dual-edition-module-migration

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Migrate modules between shared src/opensource/ code and enterprise overlays under enterprise/src/opensource/, while preserving the src/opensource boundary and existing component override points.

Core Features & Use Cases

  • Maintain a single source of truth in src/opensource/ while delivering enterprise-specific behavior via mirrored overlays under enterprise/src/opensource/.
  • Remove outdated src/variant facades and align all imports to @/opensource/..., using overlays to preserve behavior.
  • Follow a minimal, boundary-preserving migration workflow that isolates changes to the enterprise overlay and the shared baseline.

Quick Start

Identify a module that exists in both OSS and enterprise editions and implement a mirrored enterprise overlay under enterprise/src/opensource.

Frequently Asked Questions about dual-edition-module-migration

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I sync modules between OSS and enterprise editions without breaking shared imports?

To sync dual-edition modules, you implement a mirrored enterprise overlay under enterprise/src/opensource that preserves the shared src/opensource boundary while applying a smallest-overwrite strategy for enterprise-specific behavior.

What is an enterprise overlay and when do I need it for code architecture?

An enterprise overlay is a mirrored module structure under enterprise/src/opensource that delivers enterprise-specific behavior while maintaining a single source of truth in the shared src/opensource baseline, needed when modules exist in both editions.

How do I remove legacy variant facades and align imports during module migration?

Remove outdated src/variant facades and align all imports to @/opensource/... paths, using the enterprise overlay to preserve behavior so imports resolve to the correct mirrored files during runtime validation.

What's the best way to maintain a shared code baseline while delivering enterprise features?

Maintain a single source of truth in src/opensource/ while delivering enterprise-specific behavior via mirrored overlays under enterprise/src/opensource/, following a minimal boundary-preserving migration workflow.

How does import validation work with mirrored enterprise overlays?

Import validation enforces migration discipline by checking that imports resolve to correct mirrored files, verifying overlays and boundary compliance during runtime to ensure the smallest-overwrite strategy is maintained.

Can I migrate modules that only exist in the enterprise edition to the shared baseline?

This migration targets modules that exist in both OSS and enterprise editions, implementing mirrored enterprise overlays under enterprise/src/opensource to preserve the shared boundary and existing component override points.