plugin-new-frontend-system-support

Dual frontend-system support uses a dual-entry point to keep existing src/plugin.ts for old routes and add src/alpha.tsx for new PageBlueprint-based pages, allowing Backstage plugins to run in both environments without forcing immediate consumer migration.

A dual-entry point is an architecture pattern for Backstage plugin migration that maintains the old src/plugin.ts entry alongside a new src/alpha.tsx entry, enabling PageBlueprint-based pages while preserving compatibility with the old frontend system.

You need PageBlueprint to implement new frontend system pages in Backstage. When migrating shared plugins, you use PageBlueprint in the alpha entry point to define pages while keeping the old routes intact for legacy compatibility.

To handle NFS page variants during Backstage plugin migration, implement NFS components that render independently without the old page shell. This allows the new frontend system to display pages correctly without legacy wrapper dependencies.

Migrating Backstage APIs to ApiBlueprint involves updating your alpha entry point exports to use ApiBlueprint patterns. This separates API ownership and route definitions between the old and new frontend systems for a smooth transition.

You should not use a dual-entry approach for Backstage plugin migration if your plugin is private and unpublished. Dual-entry implementation is designed for published or shared plugins that need to work across both old and new frontend environments for consumers.