OCPBUGS-84338: Update resolveDynamicModuleMaps to skip unavailable packages

[vojtechszocs]

Analysis / Root cause

When a Console plugin does not install all packages in dynamicModulePatternFlyPackages (default list) or all packages in ConsoleRemotePlugin setting sharedDynamicModuleSettings.packageSpecs (override list) then it causes a confusing message during the webpack build:

Cannot resolve base path for package @patternfly/react-data-view

In other words, if a Console plugin does not use e.g. @patternfly/react-data-view then we should not attempt to process dynamic modules for that vendor package.

Solution description

Update resolveDynamicModuleMaps function to skip unavailable vendor packages.

Screenshots / screen recording

When building Console Networking plugin

Test setup

Clone Console Networking plugin and run npm run build to see the above message.

Reviewers and assignees

/assign @logonoff

Summary by CodeRabbit

• Refactor
  • Improved dependency detection and validation across the plugin SDK's module resolution system, ensuring more consistent behavior when handling shared modules and dynamic module imports during plugin builds.

[coderabbitai]

📝 Walkthrough

Walkthrough

The changes refactor dependency validation logic in the webpack plugin infrastructure by introducing a reusable dependency-existence predicate. The ConsoleRemotePlugin now uses this predicate for shared module validation instead of direct lookups, while DynamicModuleImportPlugin accepts an optional isPackageAvailable parameter to conditionally process package specifications based on dependency availability. This enables short-circuit logic that skips unnecessary file operations when packages are unavailable, improving consistency and reducing redundant path resolution attempts across the plugin configuration.

🚥 Pre-merge checks | ✅ 11 | ❌ 1

❌ Failed checks (1 inconclusive)

Check name	Status	Explanation	Resolution
Test Structure And Quality	❓ Inconclusive	Pull request modifies TypeScript webpack plugins (ConsoleRemotePlugin.ts, DynamicModuleImportPlugin.ts) but contains no Ginkgo test code. Ginkgo is a Go testing framework; this is TypeScript/JavaScript frontend code.	Clarify whether test code review was intended. If testing is needed, provide associated test files or confirm no tests were modified in this PR.

✅ Passed checks (11 passed)

Check name	Status	Explanation
Description check	✅ Passed	The description covers Analysis/Root cause (the problem), Solution description, Test setup, and includes a screenshot showing the actual error. However, it lacks several template sections like explicit test cases, Browser conformance checklist, and clear reviewer assignments.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Stable And Deterministic Test Names	✅ Passed	The custom check for stable and deterministic Ginkgo test names is not applicable to this pull request as it contains only TypeScript webpack plugin changes in the frontend package with no Go test file modifications.
Microshift Test Compatibility	✅ Passed	PR modifies only TypeScript/webpack plugin source code; custom check applies exclusively to Ginkgo e2e tests in Go, which are not modified.
Single Node Openshift (Sno) Test Compatibility	✅ Passed	PR modifies TypeScript webpack plugins for build-time dynamic module resolution, not Go e2e tests, so SNO compatibility check does not apply.
Topology-Aware Scheduling Compatibility	✅ Passed	PR modifies only webpack build-time plugin configuration files within @console/dynamic-plugin-sdk, with no Kubernetes deployment manifests, operator code, controllers, or pod scheduling constraints present.
Ote Binary Stdout Contract	✅ Passed	OTE Binary Stdout Contract check is not applicable; PR modifies only TypeScript webpack plugins for OpenShift Console frontend, not Go test code.
Ipv6 And Disconnected Network Test Compatibility	✅ Passed	PR modifies only TypeScript webpack plugin files with no Ginkgo e2e tests added; custom check for test compatibility is not applicable.
Title check	✅ Passed	The PR title clearly and specifically describes the main change: updating resolveDynamicModuleMaps to skip unavailable packages, which directly addresses the root cause of confusing webpack build messages.

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

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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

[coderabbitai]

🧹 Nitpick comments (1)

frontend/packages/console-dynamic-plugin-sdk/src/webpack/DynamicModuleImportPlugin.ts (1)

53-55: Add regression coverage for the unavailable-package short-circuit.

Please add tests for both paths: predicate false (package skipped) and default behavior (package processed), so this fix stays locked.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@frontend/packages/console-dynamic-plugin-sdk/src/webpack/DynamicModuleImportPlugin.ts`
around lines 53 - 55, Add two unit tests covering the short-circuit in
DynamicModuleImportPlugin: one test where isPackageAvailable(pkgName) is
stubbed/mocked to return false and asserts that the package is skipped (acc
unchanged / no import created), and one test where isPackageAvailable returns
true and asserts the default processing happens (package is added/processed).
Target the code path that contains the if (!isPackageAvailable(pkgName)) return
acc; check by invoking the function/method that iterates packages in
DynamicModuleImportPlugin and use assertions on the returned accumulator or
side-effects to validate both behaviors.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In
`@frontend/packages/console-dynamic-plugin-sdk/src/webpack/DynamicModuleImportPlugin.ts`:
- Around line 53-55: Add two unit tests covering the short-circuit in
DynamicModuleImportPlugin: one test where isPackageAvailable(pkgName) is
stubbed/mocked to return false and asserts that the package is skipped (acc
unchanged / no import created), and one test where isPackageAvailable returns
true and asserts the default processing happens (package is added/processed).
Target the code path that contains the if (!isPackageAvailable(pkgName)) return
acc; check by invoking the function/method that iterates packages in
DynamicModuleImportPlugin and use assertions on the returned accumulator or
side-effects to validate both behaviors.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository YAML (base), Central YAML (inherited)

Review profile: CHILL

Plan: Enterprise

Run ID: a9958391-d71d-4bbb-9720-76a462a6d167

📥 Commits

Reviewing files that changed from the base of the PR and between 0a66c88 and 8e68874.

📒 Files selected for processing (2)

• frontend/packages/console-dynamic-plugin-sdk/src/webpack/ConsoleRemotePlugin.ts
• frontend/packages/console-dynamic-plugin-sdk/src/webpack/DynamicModuleImportPlugin.ts

📜 Review details

🔇 Additional comments (4)

frontend/packages/console-dynamic-plugin-sdk/src/webpack/ConsoleRemotePlugin.ts (3)

47-48: Good extraction of dependency-presence check.

This helper centralizes package-availability logic and avoids relying on truthy version strings.

---

144-144: Nice consistency between deprecation warnings and shared-module validation.

Using the same predicate in both paths removes drift and makes behavior predictable.

Also applies to: 163-163

---

382-386: Correctly wires package availability into dynamic module map resolution.

Passing the predicate here directly addresses the noisy “Cannot resolve base path” scenario for unused packages.

frontend/packages/console-dynamic-plugin-sdk/src/webpack/DynamicModuleImportPlugin.ts (1)

37-38: Backward-compatible API extension looks solid.

Defaulting isPackageAvailable to () => true preserves existing callers while enabling selective resolution.

[logonoff]

/retitle OCPBUGS-84338: Update resolveDynamicModuleMaps to skip unavailable packages

[openshift-ci-robot]

@vojtechszocs: This pull request references Jira Issue OCPBUGS-84338, which is valid. The bug has been moved to the POST state.

3 validation(s) were run on this bug

• bug is open, matching expected state (open)
• bug target version (5.0.0) matches configured target version for branch (5.0.0)
• bug is in the state New, which is one of the valid states (NEW, ASSIGNED, POST)

The bug has been updated to refer to the pull request using the external bug tracker.

Details

In response to this:

Analysis / Root cause

When a Console plugin does not install all packages in dynamicModulePatternFlyPackages (default list) or all packages in ConsoleRemotePlugin setting sharedDynamicModuleSettings.packageSpecs (override list) then it causes a confusing message during the webpack build:

Cannot resolve base path for package @patternfly/react-data-view

In other words, if a Console plugin does not use e.g. @patternfly/react-data-view then we should not attempt to process dynamic modules for that vendor package.

Solution description

Update resolveDynamicModuleMaps function to skip unavailable vendor packages.

Screenshots / screen recording

When building Console Networking plugin

Test setup

Clone Console Networking plugin and run npm run build to see the above message.

Reviewers and assignees

/assign @logonoff

Summary by CodeRabbit

• Refactor
• Improved dependency detection and validation across the plugin SDK's module resolution system, ensuring more consistent behavior when handling shared modules and dynamic module imports during plugin builds.

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]

/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:

• 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

[logonoff]

Tested by removing data view from monitoring plugin and applying this patch locally in node modules - confusing message no longer present

/verified by @logonoff

[openshift-ci-robot]

@logonoff: This PR has been marked as verified by @logonoff.

Details

In response to this:

Tested by removing data view from monitoring plugin and applying this patch locally in node modules - confusing message no longer present

/verified by @logonoff

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-merge-bot]

/retest-required

Remaining retests: 0 against base HEAD 924065f and 2 for PR HEAD 8e68874 in total

[openshift-ci]

@vojtechszocs: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/backend	8e68874	link	true	/test backend

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.