2025-04-10 Frontend Working Group Meeting Notes: Customizing Paragon components, build optimization

Date, time, location

Date:Apr 10, 2025 at 15:00 UTC (timezone converter)
Location: https://meet.google.com/wxe-myxy-uei

Discussion topic(s)

One, maybe two topics to be presented or discussed in depth in the upcoming meeting.

[proposal/discuss] feat: introduce AlertButtonWithConfig with variant from config by adamstankiewicz · Pull Request #789 · openedx/frontend-platform
1. tl;dr; 2U/edX.org’s @edx/elm-theme (design tokens compatible brand package) calls for variant=”brand” by default in the Paragon’s Alert component actions; however, this is passed by consuming MFE, i.e. not configurable through the design tokens alone, AFAIK.
  1. Alternatives to explore:
    1. Config-aware components within @edx/frontend-platform (above approach)
      1. When we need more customization, we can back to this discussion about config-aware vs. plugin slots.
    2. Override CSS in brand package directly, following the current paradigm of _overrides.scss in brand packages (e.g., brand-openedx, brand-edx.org)
      1. Need to manually write CSS to override Paragon/Bootstrap class names (e.g., .pgn__alert-actions .btn-primary).
    3. Expose alias design token(s) specifically for this use case, where the Paragon v23 CSS can consume its resulting SCSS variable. For brand packages (e.g., edx/elm-theme), we’d override the related design token(s), instead of writing CSS overrides.
      1. Note: still needs some discovery.
      2. Just adds more granularity/flexibility/control.
      3. Let’s go with this!
devDependencies vs. dependencies
1. Context:
2. Webpack vs. Vite vs. ???
  1. Webpack config is complex and our MFEs relies on our config.
  2. Vite has issues with module federation in the past, but maybe should be revisited
  3. Can we rely on more out-of-the-box config?
  4. React Router 7 (Open edX is currently on React Router 6) supports library mode (what we use today) & framework mode (SSR); however, Framework mode assumes you use Vite
    1. TBD if React Router intends to support Webpack in the future (e.g., Webpack plugin for react-router 7 · remix-run react-router · Discussion #11972).
3. Open question / goal: Could MFEs be agnostic about the bundler?
  1. How to deal with bundler-specific config custom to Open edX (e.g., ParagonWebpackPlugin)?
    1. Could replicate behavior for multiple bundlers.
    2. Many Webpack plugins are compatible with RSBuild.
Support multiple ids for plugin slots · Issue #109 · openedx/frontend-plugin-framework
1. Any gotchas come to mind?
[experiment] Generating TypeScript types from Open API schemas
1. Goal: Can we avoid having to manually write types for API response metadata, and instead rely on generating types from a backend’s Open API schema?
2. GitHub - openapi-ts/openapi-typescript: Generate TypeScript types from OpenAPI 3 specs
  1. Documentation
3. Assumes backend service utilizes an Open API schema and exposes a way to download it as an GET API.
  1. E.g., drf-spectacular (docs)
  2. Example:
    1. https://enterprise-access.edx.org/api/schema/redoc/
    2. Download schema: https://enterprise-access.edx.org/api/schema/

🎥Recording

Participants

Adam Stankiewicz, Adolfo Brandes, Brian Smith, Hamzah Ullah, Hina Khadim, Juan Carlos Iasenza, Max Frank, Régis Behmo

🤖 Summary

💡 1. Alert Button Variant & Design Tokens Discussion

Presenter: Adam Stankiewicz

Context: Migration to Paragon v23 and usage of the Elm theme.
Problem: Alert buttons default to a primary variant; Elm wants brand as default, but overriding this globally in MFs is not ideal.
Proposed Solutions:
1. Aware/configurable wrapper component (e.g., DefaultAlertButton)
2. Brand package override using CSS variables
3. Use of design tokens with a new token to control the alert button variant (preferred option)
Outcome:
- General consensus to explore Option 3 (design tokens) as the cleanest path.
- Recognized that plugin slots might be viable for more extensive use cases but come with complexity.

🧩 2. Dev Dependencies vs Dependencies

Presenter: Brian Smith

Goal: Clarify what belongs in dependencies vs. devDependencies
Proposal:
- Only include in dependencies what ends up in the user-facing bundle.
- Tools like Webpack should stay in devDependencies if not directly used in runtime.
Discussion:
- Régis initially disagreed but changed stance after replacing Webpack with RSBuild.
- Agreement that using npm install --omit=dev should still work for building in containerized environments.

🛠️ 3. Build Performance, Webpack vs. RSBuild

Presenter: Régis Behmo

Issues Identified:
- Large dependency size (e.g., 1.3GB for profile MF)
- Long build times (~1m 40s for 5.5K LOC)
- Large production bundles (~2MB)
Proposal: Explore RSBuild as an alternative to Webpack for faster builds and simpler configs.
Concerns Raised:
- Webpack is deeply integrated (e.g., plugin support, design tokens).
- Replacing Webpack is non-trivial and may affect module federation and plugin functionality.
Consensus:
- Worth exploring RSBuild in isolated cases, but any switch requires extensive evaluation and alignment across teams.

🔄 4. Plugin Slot ID Aliases