mcpField
R
rhdh-plugin-nfs-migration

rhdh-plugin-nfs-migration

github.com/redhat-developerDevelopment1950 installsUpdated 1d ago
Repository

About rhdh-plugin-nfs-migration

rhdh-plugin-nfs-migration is a skill for developers moving frontend plugins from the legacy frontend system to NFS. It inventories extensions before migrating them by type and preserves legacy exports unless a breaking change is explicitly approved.

Key features

  1. 01Inventory plugin extensions and exports
  2. 02Migrate extension types to NFS Blueprints
  3. 03Preserve compatibility for legacy consumers
  4. 04Follow guidance by extension type
  5. 05Check types from the workspace root

Use cases

  1. 01Migrate pages, entity content, or API factories
  2. 02Move translations and RHDH extensions
  3. 03Check migrated types and legacy consumer compatibility

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/redhat-developer/rhdh-skills --skill rhdh-plugin-nfs-migration

After installing, type/rhdh-plugin-nfs-migrationin Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

agents/
openai.yaml
references/
app-setup.md
gotchas.md
migrate-app-level.md
migrate-entity-content.md
migrate-page.md
migrate-rhdh-extensions.md
migrate-translations.md
mount-point-mapping.md
operator-config.md
overview.md
package-json.md
reference-prs.md
support.md
testing-rhdh.md
verification.md
workflows/
migrate-nfs.md
test-nfs-plugin.md

Details

From the project README

RHDH Plugin NFS Migration

Own the shape of a frontend plugin's extensions as it moves from the legacy frontend system to NFS. Discover what the plugin exports before changing anything, migrate one extension type at a time, and keep legacy consumers compiling until the user explicitly approves a breaking change.

Start here

  1. Read the plugin's package.json, src/plugin.ts or src/plugin.tsx, route refs, API factories, exported components, and app-config.dynamic.yaml.
  2. Read the workspace's own AGENTS.md or CLAUDE.md; repository rules beat anything written here.
  3. List every discovered extension to the user before editing.
  4. Inspect branch and status before modifying files, and protect uncommitted work.

Route by outcome

OutcomeLoad and follow
Migrate a plugin to NFSworkflows/migrate-nfs.md
Test a migrated plugin in RHDHworkflows/test-nfs-plugin.md
Explain NFS before migratingreferences/overview.md
Migrate pages or API factoriesreferences/migrate-page.md
Migrate entity tabs or cardsreferences/migrate-entity-content.md
Migrate translationsreferences/migrate-translations.md
Migrate RHDH drawers, header items, homepage widgetsreferences/migrate-rhdh-extensions.md
Migrate app-level wrappers or root elementsreferences/migrate-app-level.md
Translate a legacy dynamic mount point into an extensionreferences/mount-point-mapping.md
Update package exportsreferences/package-json.md
Set up or update the NFS dev appreferences/app-setup.md
Verify the migrationreferences/verification.md
Reach RHDH operator app.extensions or app.routes.bindingsreferences/operator-config.md
Troubleshoot a failed migrationreferences/gotchas.md, then references/support.md
Find a real migrated plugin to copyreferences/reference-prs.md

Boundaries

  • This skill owns extension shape: which Blueprint replaces which legacy extension, where it attaches, and what the package exports. It does not choose @backstage/* version numbers.
  • /rhdh-backstage-upgrade owns version numbers: which Backstage release to move to and how to get the dependency set there. When the plugin's @backstage/* dependencies are too old for the Blueprints this migration needs, invoke it by name first, then return here.
  • /backstage-api-changes owns the NFS API deltas between the early alpha and the current GA surface — removed NavItemBlueprint, the configSchema replacement for config.schema, renamed blueprint params. Invoke it by name when migrating a plugin that was already migrated against an older NFS API, or when a Blueprint param produces a TypeScript error.
  • /rhdh-plugin-export owns exporting and packaging the migrated plugin.
  • /rhdh-plugin-wiring owns generating dynamic-plugins.yaml configuration.
  • /rhdh-local owns running a local RHDH instance and applying plugin configuration to it.
  • /rhdh-pr-create owns staging, commits, and pull requests. Leave changed files unstaged and list them when you finish.

Invoke a named skill and describe the handoff in the conversation. Never open another skill's files.

Invariants

  • NFS is not GA. Default to the alpha approach: NFS at ./alpha, legacy untouched at the root export. Use the colocated approach only when the user wants both APIs from one import path.
  • Keep component-level imports (useApi, useRouteRef) on @backstage/core-plugin-api so the same components serve both export paths. Reach for compatWrapper() only when a component needs a legacy context provider that NFS does not supply.
  • Core blueprints come from @backstage/frontend-plugin-api. RHDH-only blueprints such as AppDrawerContentBlueprint and GlobalHeaderMenuItemBlueprint come from @red-hat-developer-hub/*. Do not mix the two namespaces.
  • Put entity content and cards directly in the plugin's extensions array. Use createFrontendModule only to target a different plugin — translations at pluginId: 'app', homepage widgets at pluginId: 'home'.
  • Legacy exports stay available. A breaking change to a legacy consumer needs explicit user approval.
  • Run yarn tsc from the workspace root, not the plugin directory, so consumer import breakage surfaces.
  • Do not stage, commit, push, or open a pull request here.

Completion

Report the extensions discovered and their NFS equivalents, the export approach chosen, the files changed and left unstaged, the verification commands run and their results, any legacy consumer risk, and the named skill to invoke next for export, wiring, local testing, or publication.

Comments

Markdown supported