fix: treat @openedx/frontend-build as an optional peerDep to avoid direct dep in consuming MFEs

[adamstankiewicz]

Related discussions:

• chore: reorganize prod dependencies #787
• Clarify how devDependencies should be used for NPM packages (OEP-67: Standard Tools and Technologies) open-edx-proposals#615

Corresponding PR:

• [discovery, DO NOT MERGE] fix: optional frontend-build peerDep in frontend-platform frontend-app-communications#221

Description:

Demonstrates treating @openedx/frontend-build as an optional peer dependency within @edx/frontend-platform, such that consuming MFEs no longer considers @openedx/frontend-build as a direct dependency, via:

{
  "peerDependenciesMeta": {
      "@openedx/frontend-build": {
        "optional": true
      }
    }
}

From @brian-smith-tcril here:

As for frontend-build specifically, the fact that it is currently in frontend-platform's peerDependencies means that MFEs adding frontend-platform as a direct dependency end up with a non-dev dependency on frontend-build. In frontend-app-communications for example, @testing-library/react is in the package lock with "dev": true, while frontend-build (which is in package.json as a dev dep) is not in package-lock.json as dev.

This indeed does pose a problem for consuming MFEs as @openedx/frontend-build should not be considered as a direct dependencies when the MFE itself installs @openedx/frontend-build as a devDependencies.

Why might this optional peer dependency might work?

Npm will not automatically install optional peer dependencies (docs)

Testing the optional peer dependency approach with frontend-app-communications (PR), @openedx/frontend-build is no longer treated a direct dependency, but instead receives devOptional: true in package-lock.json (source).

While npm ci --omit=dev doesn't omit @openedx/frontend-build from being installed for the MFE, npm ci --omit=dev --omit=optional would.

Merge checklist:

• Consider running your code modifications in the included example app within frontend-platform. This can be done by running npm start and opening http://localhost:8080.
• Consider testing your code modifications in another local micro-frontend using local aliases configured via the module.config.js file in frontend-build.
• Verify your commit title/body conforms to the conventional commits format (e.g., fix, feat) and is appropriate for your code change. Consider whether your code is a breaking change, and modify your commit accordingly.

Post merge:

• After the build finishes for the merged commit, verify the new release has been pushed to NPM.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 86.79%. Comparing base (455c45e) to head (41031e4).
Report is 15 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #790   +/-   ##
=======================================
  Coverage   86.78%   86.79%           
=======================================
  Files          48       48           
  Lines        1400     1401    +1     
  Branches      294      294           
=======================================
+ Hits         1215     1216    +1     
  Misses        172      172           
  Partials       13       13           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 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.

[brian-smith-tcril]

Let's go for it!