Replace barrel-file ternaries with webpack platform aliases and usePlatformFeatures (HMS-10834)

[kingsleyzissou]

Summary

Replace the 19 process.env.IS_ON_PREMISE ternaries in barrel files with build-time webpack alias resolution, and introduce a usePlatformFeatures hook that translates the raw isOnPremise boolean into semantic capability flags for component-level branching.

Changes

• Webpack alias swap for hook resolution — Paired alias files (index.hosted.ts / index.onprem.ts) replace the ternary-laden barrel files in backend/, contentSources/, and useGetEnvironment. Each webpack config resolves @/store/api/backend to the correct platform file at build time, so consumers don't change and the other platform's code never enters the module graph.

• usePlatformFeatures hook — A thin hook that maps isOnPremise to named capabilities (canCrossArchBuild, showDevelopmentReleases, securitySectionLabel, etc.). Migrated 5 components as proof-of-concept; remaining components can adopt incrementally.

• Cleanup of process.env.IS_ON_PREMISE in shared hooks — contentSources/hooks.tsx and backend/hooks.tsx now use the existing selectIsOnPremise selector instead of reading the env var directly.

• Test coverage — Export-surface tests for both alias files, alias-resolution tests verifying vitest wiring, usePlatformFeatures unit tests, and updated component tests covering both platform behaviors via preloadedState.

Notes

Build-time platform file resolution is a well-established pattern across the ecosystem:

• React Native — Metro bundler resolves .ios.ts / .android.ts extensions automatically per target platform
• React Native Web — extends the convention with .web.ts for browser targets
• Node.js conditional exports — package.json exports field resolves different entry points based on conditions ("browser", "node", "import")
• Preact — the entire preact/compat story is a resolve.alias swap for React
• Webpack docs — resolve.alias is explicitly recommended for environment-specific builds

JIRA: HMS-10834

[kingsleyzissou]

This is probably a more elegant solution than:
#4508

[codecov]

Codecov Report

❌ Patch coverage is 90.32258% with 6 lines in your changes missing coverage. Please review.
✅ Project coverage is 75.75%. Comparing base (71ce8aa) to head (4202097).

Files with missing lines	Patch %	Lines
src/Utilities/useGetEnvironment/index.hosted.ts	50.00%	5 Missing and 1 partial ⚠️

@@            Coverage Diff             @@
##             main    #4531      +/-   ##
==========================================
+ Coverage   75.51%   75.75%   +0.23%     
==========================================
  Files         225      227       +2     
  Lines        7214     7219       +5     
  Branches     2673     2667       -6     
==========================================
+ Hits         5448     5469      +21     
+ Misses       1519     1505      -14     
+ Partials      247      245       -2     

Files with missing lines	Coverage Δ
...Components/CreateImageWizard/CreateImageWizard.tsx	84.23% <ø> (ø)
...Wizard/steps/ImageOutput/components/ArchSelect.tsx	95.83% <100.00%> (+4.16%)	⬆️
...ard/steps/ImageOutput/components/BlueprintMode.tsx	100.00% <100.00%> (+13.51%)	⬆️
...ard/steps/ImageOutput/components/ReleaseSelect.tsx	98.24% <100.00%> (+3.33%)	⬆️
...Wizard/steps/Packages/components/PackageSearch.tsx	81.21% <100.00%> (+0.04%)	⬆️
...ImageWizard/steps/Review/Footer/CreateDropdown.tsx	61.40% <ø> (ø)
...teImageWizard/steps/Review/Footer/EditDropdown.tsx	50.00% <ø> (ø)
...rd/steps/Review/components/ImageOverview/index.tsx	100.00% <100.00%> (ø)
...eWizard/steps/Review/components/Security/index.tsx	88.88% <100.00%> (-1.12%)	⬇️
src/Components/LandingPage/LandingPage.tsx	88.23% <ø> (ø)
... and 8 more

---

Continue to review full report in Codecov by Harness.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 71ce8aa...4202097. Read the comment docs.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[kingsleyzissou]

/jira-epic HMS-10502

[sourcery-ai]

Hey - I've found 1 issue, and left some high level feedback:

• The new usePlatformFeatures hook is starting to accumulate a broad set of unrelated flags; consider grouping by concern (e.g. release-selection, architecture, security/labels, export behavior) or splitting into smaller hooks to keep call sites and future additions easier to reason about.
• There are several duplicated alias configurations across fec.config.js, cockpit/webpack.config.ts, vitest.config.ts, and tsconfig.json (backend/contentSources/useGetEnvironment); it may be worth centralizing or at least co-locating these definitions to reduce the risk of the platform-specific resolution getting out of sync.
• The new type assertions like requestBody as CreateBlueprintRequest and onPremRequest as ApiContentUnitSearchRequest suggest the API typings don’t quite match real call shapes; if possible, tighten the shared types or introduce narrower request types instead of relying on as casts at the call sites.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The new `usePlatformFeatures` hook is starting to accumulate a broad set of unrelated flags; consider grouping by concern (e.g. release-selection, architecture, security/labels, export behavior) or splitting into smaller hooks to keep call sites and future additions easier to reason about.
- There are several duplicated alias configurations across `fec.config.js`, `cockpit/webpack.config.ts`, `vitest.config.ts`, and `tsconfig.json` (backend/contentSources/useGetEnvironment); it may be worth centralizing or at least co-locating these definitions to reduce the risk of the platform-specific resolution getting out of sync.
- The new type assertions like `requestBody as CreateBlueprintRequest` and `onPremRequest as ApiContentUnitSearchRequest` suggest the API typings don’t quite match real call shapes; if possible, tighten the shared types or introduce narrower request types instead of relying on `as` casts at the call sites.

## Individual Comments

### Comment 1
<location path="src/Components/CreateImageWizard/steps/Packages/components/PackageSearch.tsx" line_range="261-269" />
<code_context>
+        // On-prem uses a different request shape with `packages` field;
+        // this branch is unreachable in the hosted build but the code
+        // is shared across targets.
+        const onPremRequest = {
+          packages: [debouncedSearchTerm],
+          architecture: arch,
+          distribution,
+        };
         searchDistroRpms({
-          apiContentUnitSearchRequest: {
-            packages: [debouncedSearchTerm],
-            architecture: arch,
-            distribution,
-          },
+          apiContentUnitSearchRequest:
+            onPremRequest as ApiContentUnitSearchRequest,
         });
</code_context>
<issue_to_address>
**suggestion:** Avoid the loose type assertion when building the on-prem search request.

The loose cast here means future changes to `ApiContentUnitSearchRequest` (e.g., renamed fields or different shapes) won’t be caught at compile time and could fail at runtime. Instead, either type `onPremRequest` directly as `ApiContentUnitSearchRequest`:

```ts
const onPremRequest: ApiContentUnitSearchRequest = {
  packages: [debouncedSearchTerm],
  architecture: arch,
  distribution,
};
```

or create a small helper that returns `ApiContentUnitSearchRequest` for the on-prem branch so the compiler enforces the contract.

```suggestion
        const onPremRequest: ApiContentUnitSearchRequest = {
          packages: [debouncedSearchTerm],
          architecture: arch,
          distribution,
        };
        searchDistroRpms({
          apiContentUnitSearchRequest: onPremRequest,
        });
```
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[kingsleyzissou]

More elegant than the other PR, but introduces other problems. Maybe we stick with the status quo or try figure out how to run some of the test suite for on-prem (not trivial)