CONSOLE-3769: Phase 2 of using OpenShift Dynamic Plugin SDK

[logonoff]

This PR updates Console dynamic plugin runtime infrastructure to use lib-core code from OpenShift Dynamic Plugin SDK ("upstream").

Console runtime plugin infrastructure has been updated in to support both current (legacy) and new (upstream) plugin entry schemes.

Console plugins built with updated ConsoleRemotePlugin will now use the default entryCallbackSettings provided by upstream's DynamicRemotePlugin.

There is one difference between Console legacy and upstream's entryCallbackSettings: pluginId no longer includes the version string.

-      entryCallbackSettings: { // our old config
-        name: 'loadPluginEntry',
-        pluginID: `${name}@${version}`,
-      },
+     entryCallbackSettings: { // new default options from DynamicRemotePlugin
+        name: '__load_plugin_entry__',
+        pluginID: name,
+     },

When upstream's PluginLoader tries to load a plugin, it makes the assumption in PluginLoader.loadPluginScripts that the plugin name passed to the plugin entry callback always matches the plugin name.

However, this precondition was not met previously. To solve this, we introduce a new window.__load_plugin_entry__ global method, which is the default plugin callback provided by upstream. This is now the default plugin entry callback for plugins, starting with 4.22.

After upstream PluginStore registers that callback, we register our own window.loadPluginEntry method, which strips the version from the plugin name, providing backwards compatibility for plugins built for 4.21 or older.

How to test:

• Feature flags: Open two development console instances connected to the same cluster. Compare the state of the feature flags in the main branch (using window.store.getState().FLAGS.toObject()) with the new PluginStore (using window.pluginStore.featureFlags). The keys and values of both should be identical, given both pages are fully loaded, and both the page and cluster state are also identical. You can do the comparison by casting both to a JSON object using JSON.stringify and then performing a semantic diff
• Optional dependencies: ensure optional dependencies manual tests still work
• Plugin loading: in a cluster, ensure core plugins (e.g., monitoring-plugin, networking-plugin, kubevirt-plugin, acm, etc.) work exactly the same as before. Build dynamic-demo-plugin from this branch and ensure that works as well (this tests the new plugin entry callback)
• Allowed plugin names: In a development instance, try to manually register a plugin. There should be an error:

  window.pluginStore.loadPlugin({
    name: 'foo', version: '1.0.0',
    registrationMethod: 'local',
  }); // This should not work

• Sorted extensions: Perform the same verification steps as in OCPBUGS-43792: Load extensions in same order as plugins listed in SERVER_FLAGS global #14902 and ensure that there are no regressions in regards to extension order, e.g., in the CreateProjectModal extension
• Translated extensions: Translation should still work when the language is being changed in user preferences

Other notable changes:

• "Console active plugins module generated with 0 errors and 0 warnings" will no longer show, we will log only if there are problems now.
• Active plugins are renamed to local plugins to align with nomenclature in CONSOLE-4910: Add support for loading plugins from local manifests dynamic-plugin-sdk#281
• Remove subscribeToExtensions and subscribeToDynamicPlugins subscription services. React hooks are now the only way to consume extensions
• All console.flag side effects are now handled by FeatureFlagExtensionLoader
• Introduce a renderHookWithProviders, akin to our renderWithProviders
• We are now free of yarn's incorrect "resolutions" warnings (the last one was @types/lodash which is fixed in this PR)
• @openshift/dynamic-plugin-sdk is added to shared modules so that the PluginStoreContext context can be shared
• pluginID is no longer a field in LoadedExtension

Not-in-scope follow up work:

• Remove our codeRef handling code by fixing useResolvedExtensions upstream so we can consume it here

[openshift-ci-robot]

@logonoff: This pull request references CONSOLE-3705 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target either version "4.22." or "openshift-4.22.", but it targets "openshift-4.15" instead.

Details

In response to this:

This PR updates Console dynamic plugin runtime infrastructure to use lib-core code from OpenShift Dynamic Plugin SDK ("upstream").

Console runtime plugin infrastructure has been updated in to support both current (legacy) and new (upstream) plugin entry schemes.

Console plugins built with updated ConsoleRemotePlugin will now use the default entryCallbackSettings provided by upstream's DynamicRemotePlugin.

There is one difference between Console legacy and upstream's entryCallbackSettings: pluginId no longer includes the version string.

-      entryCallbackSettings: {
-        name: 'loadPluginEntry',
-        pluginID: `${name}@${version}`,
-      },
+     entryCallbackSettings: {
+        name: '__load_plugin_entry__',
+        pluginID: name,
+     },

When upstreams PluginLoader tries to load a plugin, it makes the assumption in PluginLoader.loadPluginScripts that the plugin name passed to the plugin entry callback always matches the plugin name.

However, this precondition was not met previously. To solve this, we introduce a new window.__load_plugin_entry__ global method, which is the default plugin callback provided by upstream. After this is added, we add our own window.loadPluginEntry method, which strips the version from the plugin name, providing backwards compatibility for plugins built for 4.21 or older.

Other notable changes:

• "Console active plugins module generated with 0 errors and 0 warnings" will no longer show, we will log only if there are problems now.
• Active plugins are renamed to local plugins to align with nomenclature in CONSOLE-4910: Add support for loading plugins from local manifests dynamic-plugin-sdk#281

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[coderabbitai]

📝 Walkthrough

Walkthrough

Replaces legacy Console plugin runtime and store with SDK-managed PluginStore and hooks; migrates consumers from metadata/pluginID to manifest/uid; introduces Jest Webpack mock; adds resource-sidebar samples hook; removes many legacy runtime modules and tests; updates numerous callers and test providers.

Changes

Cohort / File(s)	Summary
Jest webpack mock & loader frontend/__mocks__/webpack.ts, frontend/get-local-plugins.js, frontend/webpack.config.ts, frontend/package.json	Add Jest Webpack share-scope mock; switch val-loader to get-local-plugins.js; update Jest config (setupFiles/testPathIgnorePatterns) and add @openshift/dynamic-plugin-sdk dependency.
SDK PluginStore wiring & app integration frontend/public/plugins.ts, frontend/public/components/app.tsx, frontend/public/redux.ts, frontend/public/components/factory/modal.tsx, frontend/public/components/about-modal.tsx, frontend/public/components/notification-drawer.tsx	Introduce/export pluginStore, load local plugins via SDK, wrap app and modals with PluginStoreProvider, add featureFlagMiddleware, and migrate UI lookups to use manifest fields.
Runtime removal: loader, manifest, deps & tests frontend/packages/console-dynamic-plugin-sdk/src/runtime/* (many), multiple .../__tests__/*	Remove legacy dynamic plugin loader, manifest validation/fetch, dependency resolver, plugin-utils, and many related tests.
Init API & AppInitSDK change frontend/packages/console-dynamic-plugin-sdk/src/runtime/plugin-init.ts, frontend/packages/console-dynamic-plugin-sdk/src/app/AppInitSDK.tsx	Change init flow to accept PluginStore only, add load-and-enable logic and legacy entry callback shim, replace initPlugins with dynamicPlugins.
Console-plugin-sdk store & subscription removal frontend/packages/console-plugin-sdk/src/store.ts, frontend/packages/console-plugin-sdk/src/api/pluginSubscriptionService.ts, related tests	Delete local PluginStore, subscription service, store APIs/types and associated tests; consumers migrated to SDK contracts.
API hooks migrated to SDK / re-exports frontend/packages/console-plugin-sdk/src/api/usePluginInfo.ts, .../usePluginStore.ts (removed), .../useExtensions.ts	Replace local hook implementations with SDK hooks (usePluginInfoSDK, usePluginInfo), add referential-stability and ordering logic, adjust return types to SDK types.
Codegen: active → local & tests frontend/packages/console-plugin-sdk/src/codegen/local-plugins.ts, .../__tests__/local-plugins.spec.ts, frontend/packages/console-dynamic-plugin-sdk/src/webpack/ExtensionValidatorPlugin.ts	Rename codegen for local plugins, emit version and registrationMethod: 'local', add codeRef source getter parameter, update tests and imports.
CodeRef & types adjustments frontend/packages/console-dynamic-plugin-sdk/src/coderefs/coderef-resolver.ts, .../__tests__/coderef-resolver.spec.ts, .../utils/test-utils.ts, .../types.ts	Derive internal CodeRef symbol via SDK export, use SDK applyCodeRefSymbol, resolve code refs on cloned properties (no mutation), remove local pluginID augmentation from LoadedExtension.
Manifest-based lookups in UI & hooks multiple frontend/packages/console-app/src/components/console-operator/*, frontend/packages/console-app/src/hooks/useCSPViolationDetector.tsx, frontend/public/components/*	Replace lookups keyed by metadata/pluginName/pluginID with manifest.name/manifest.version/uid; adjust memoization and dependent logic.
pluginID → uid migration & fixture cleanup many test/data files under frontend/packages/*, frontend/public/components/*	Remove pluginID from numerous fixtures, rename props/fields to uid where applicable, update logs/keys, and update tests to use renderWithProviders.
Feature-flag extension loader refactor frontend/packages/console-app/src/components/flags/FeatureFlagExtensionLoader.tsx, frontend/public/actions/features.ts	Rework feature-flag extension handling with diff-based hooks, pending-update queue, model-flag update hook; remove legacy subscription wiring from public actions.
Sample utilities → hook migration frontend/packages/console-shared/src/hooks/useResourceSidebarSamples.ts, (deleted) frontend/packages/console-shared/src/utils/sample-utils.ts, callers (CodeEditorField.tsx, edit-yaml.tsx, resource-sidebar files)	Add useResourceSidebarSamples hook and Sample type, delete legacy sample-utils, migrate callers and adjust lazy-YAML contract.
Test helpers & provider updates frontend/packages/console-shared/src/test-utils/unit-test-utils.tsx, updated tests across repo	Add PluginStoreProvider to test render wrapper and update tests to use renderWithProviders to supply pluginStore.
Misc refactors, package metadata & changelogs assorted files (CodeEditorSidebar.tsx, package.jsons, shared-modules-meta.ts, changelogs, scripts)	Convert value imports to type-only where applicable, remove js-combinatorics devDeps, add @openshift/dynamic-plugin-sdk to shared modules, update changelogs and package-definition scripts.

Estimated code review effort

🎯 5 (Critical) | ⏱️ ~120 minutes

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 50.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The PR title 'CONSOLE-3769: Phase 2 of using OpenShift Dynamic Plugin SDK' directly and clearly summarizes the main change: migrating Console's plugin infrastructure to use the upstream OpenShift Dynamic Plugin SDK. The title is concise, specific, and aligns with the core architectural shift described in the PR objectives.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

Important

Action Needed: IP Allowlist Update

If your organization protects your Git platform with IP whitelisting, please add the new CodeRabbit IP address to your allowlist:

• ✨ 136.113.208.247/32 (new)
• 34.170.211.100/32
• 35.222.179.152/32

Failure to add the new IP will result in interrupted reviews.

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[openshift-ci-robot]

@logonoff: This pull request references CONSOLE-3769 which is a valid jira issue.

Details

In response to this:

This PR updates Console dynamic plugin runtime infrastructure to use lib-core code from OpenShift Dynamic Plugin SDK ("upstream").

Console runtime plugin infrastructure has been updated in to support both current (legacy) and new (upstream) plugin entry schemes.

Console plugins built with updated ConsoleRemotePlugin will now use the default entryCallbackSettings provided by upstream's DynamicRemotePlugin.

There is one difference between Console legacy and upstream's entryCallbackSettings: pluginId no longer includes the version string.

-      entryCallbackSettings: {
-        name: 'loadPluginEntry',
-        pluginID: `${name}@${version}`,
-      },
+     entryCallbackSettings: {
+        name: '__load_plugin_entry__',
+        pluginID: name,
+     },

When upstreams PluginLoader tries to load a plugin, it makes the assumption in PluginLoader.loadPluginScripts that the plugin name passed to the plugin entry callback always matches the plugin name.

However, this precondition was not met previously. To solve this, we introduce a new window.__load_plugin_entry__ global method, which is the default plugin callback provided by upstream. After this is added, we add our own window.loadPluginEntry method, which strips the version from the plugin name, providing backwards compatibility for plugins built for 4.21 or older.

Other notable changes:

• "Console active plugins module generated with 0 errors and 0 warnings" will no longer show, we will log only if there are problems now.
• Active plugins are renamed to local plugins to align with nomenclature in CONSOLE-4910: Add support for loading plugins from local manifests dynamic-plugin-sdk#281

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci-robot]

@logonoff: This pull request references CONSOLE-3769 which is a valid jira issue.

Details

In response to this:

This PR updates Console dynamic plugin runtime infrastructure to use lib-core code from OpenShift Dynamic Plugin SDK ("upstream").

Console runtime plugin infrastructure has been updated in to support both current (legacy) and new (upstream) plugin entry schemes.

Console plugins built with updated ConsoleRemotePlugin will now use the default entryCallbackSettings provided by upstream's DynamicRemotePlugin.

There is one difference between Console legacy and upstream's entryCallbackSettings: pluginId no longer includes the version string.

-      entryCallbackSettings: {
-        name: 'loadPluginEntry',
-        pluginID: `${name}@${version}`,
-      },
+     entryCallbackSettings: {
+        name: '__load_plugin_entry__',
+        pluginID: name,
+     },

When upstream's PluginLoader tries to load a plugin, it makes the assumption in PluginLoader.loadPluginScripts that the plugin name passed to the plugin entry callback always matches the plugin name.

However, this precondition was not met previously. To solve this, we introduce a new window.__load_plugin_entry__ global method, which is the default plugin callback provided by upstream. After this is added, we add our own window.loadPluginEntry method, which strips the version from the plugin name, providing backwards compatibility for plugins built for 4.21 or older.

Other notable changes:

• "Console active plugins module generated with 0 errors and 0 warnings" will no longer show, we will log only if there are problems now.
• Active plugins are renamed to local plugins to align with nomenclature in CONSOLE-4910: Add support for loading plugins from local manifests dynamic-plugin-sdk#281

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci-robot]

@logonoff: This pull request references CONSOLE-3769 which is a valid jira issue.

Details

In response to this:

This PR updates Console dynamic plugin runtime infrastructure to use lib-core code from OpenShift Dynamic Plugin SDK ("upstream").

Console runtime plugin infrastructure has been updated in to support both current (legacy) and new (upstream) plugin entry schemes.

Console plugins built with updated ConsoleRemotePlugin will now use the default entryCallbackSettings provided by upstream's DynamicRemotePlugin.

There is one difference between Console legacy and upstream's entryCallbackSettings: pluginId no longer includes the version string.

-      entryCallbackSettings: {
-        name: 'loadPluginEntry',
-        pluginID: `${name}@${version}`,
-      },
+     entryCallbackSettings: {
+        name: '__load_plugin_entry__',
+        pluginID: name,
+     },

When upstream's PluginLoader tries to load a plugin, it makes the assumption in PluginLoader.loadPluginScripts that the plugin name passed to the plugin entry callback always matches the plugin name.

However, this precondition was not met previously. To solve this, we introduce a new window.__load_plugin_entry__ global method, which is the default plugin callback provided by upstream. After this is added, we register our own window.loadPluginEntry method, which strips the version from the plugin name, providing backwards compatibility for plugins built for 4.21 or older.

Other notable changes:

• "Console active plugins module generated with 0 errors and 0 warnings" will no longer show, we will log only if there are problems now.
• Active plugins are renamed to local plugins to align with nomenclature in CONSOLE-4910: Add support for loading plugins from local manifests dynamic-plugin-sdk#281

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci-robot]

@logonoff: This pull request references CONSOLE-3769 which is a valid jira issue.

Details

In response to this:

This PR updates Console dynamic plugin runtime infrastructure to use lib-core code from OpenShift Dynamic Plugin SDK ("upstream").

Console runtime plugin infrastructure has been updated in to support both current (legacy) and new (upstream) plugin entry schemes.

Console plugins built with updated ConsoleRemotePlugin will now use the default entryCallbackSettings provided by upstream's DynamicRemotePlugin.

There is one difference between Console legacy and upstream's entryCallbackSettings: pluginId no longer includes the version string.

-      entryCallbackSettings: {
-        name: 'loadPluginEntry',
-        pluginID: `${name}@${version}`,
-      },
+     entryCallbackSettings: {
+        name: '__load_plugin_entry__',
+        pluginID: name,
+     },

When upstream's PluginLoader tries to load a plugin, it makes the assumption in PluginLoader.loadPluginScripts that the plugin name passed to the plugin entry callback always matches the plugin name.

However, this precondition was not met previously. To solve this, we introduce a new window.__load_plugin_entry__ global method, which is the default plugin callback provided by upstream. This is now the default plugin entry callback for plugins, starting with 4.22.

After upstream PluginStore registers that callback, we register our own window.loadPluginEntry method, which strips the version from the plugin name, providing backwards compatibility for plugins built for 4.21 or older.

Other notable changes:

• "Console active plugins module generated with 0 errors and 0 warnings" will no longer show, we will log only if there are problems now.
• Active plugins are renamed to local plugins to align with nomenclature in CONSOLE-4910: Add support for loading plugins from local manifests dynamic-plugin-sdk#281

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci-robot]

@logonoff: This pull request references CONSOLE-3769 which is a valid jira issue.

Details

In response to this:

This PR updates Console dynamic plugin runtime infrastructure to use lib-core code from OpenShift Dynamic Plugin SDK ("upstream").

Console runtime plugin infrastructure has been updated in to support both current (legacy) and new (upstream) plugin entry schemes.

Console plugins built with updated ConsoleRemotePlugin will now use the default entryCallbackSettings provided by upstream's DynamicRemotePlugin.

There is one difference between Console legacy and upstream's entryCallbackSettings: pluginId no longer includes the version string.

-      entryCallbackSettings: { // our old config
-        name: 'loadPluginEntry',
-        pluginID: `${name}@${version}`,
-      },
+     entryCallbackSettings: { // new default options from DynamicRemotePlugin
+        name: '__load_plugin_entry__',
+        pluginID: name,
+     },

When upstream's PluginLoader tries to load a plugin, it makes the assumption in PluginLoader.loadPluginScripts that the plugin name passed to the plugin entry callback always matches the plugin name.

However, this precondition was not met previously. To solve this, we introduce a new window.__load_plugin_entry__ global method, which is the default plugin callback provided by upstream. This is now the default plugin entry callback for plugins, starting with 4.22.

After upstream PluginStore registers that callback, we register our own window.loadPluginEntry method, which strips the version from the plugin name, providing backwards compatibility for plugins built for 4.21 or older.

Other notable changes:

• "Console active plugins module generated with 0 errors and 0 warnings" will no longer show, we will log only if there are problems now.
• Active plugins are renamed to local plugins to align with nomenclature in CONSOLE-4910: Add support for loading plugins from local manifests dynamic-plugin-sdk#281

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[logonoff]

2. Optional dependencies: I got different test results in this scenario 1-5-foo-has-optionaldependencies-on-bar-bar-is-not-available
   foo-plugin is not loaded while the expected results should be that foo-plugin still should be loaded, see screenshot

I only got one unexpected result following testing instructions

@yapei, hopefully this should be fixed now

[vojtechszocs]

/lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: logonoff, vojtechszocs

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• dynamic-demo-plugin/OWNERS [logonoff,vojtechszocs]
• frontend/OWNERS [logonoff,vojtechszocs]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[vojtechszocs]

Nice work @logonoff - there's some potential for follow-up improvements but this looks great overall 💯

[vojtechszocs]

2. Optional dependencies: I got different test results in this scenario 1-5-foo-has-optionaldependencies-on-bar-bar-is-not-available
   foo-plugin is not loaded while the expected results should be that foo-plugin still should be loaded, see screenshot

This test case should pass now - fixed in openshift/dynamic-plugin-sdk#305

[vojtechszocs]

@yapei Can you please re-verify test scenario 1-5-foo-has-optionaldependencies-on-bar-bar-is-not-available ?

[openshift-ci]

@logonoff: all tests passed!

Full PR test history. Your PR dashboard.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

[logonoff]

verified the optional dependencies cases manually, can do additional verification later

/verified later @vojtechszocs

[openshift-ci-robot]

@logonoff: This PR has been marked to be verified later by @vojtechszocs.

Details

In response to this:

verified the optional dependencies cases manually, can do additional verification later

/verified later @vojtechszocs

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.