2025-12-04 Frontend Working Group Meeting Notes: frontend-base and external CSS

 Date, time, location

• Date:Dec 4, 2025 at 15:00 UTC (timezone converter)

• Location: https://meet.google.com/wxe-myxy-uei

 Discussion topic(s)

• React-query conversion proposal

• frontend-base and external CSS: does it make sense to allow loading the base Paragon styles from a CDN, now that all apps use the same one? Note the motivation for the feature.

  • If the answer is no, do we still need to separate out the Paragon artifacts in the webpack build? Do we need the paragonWebpackPlugin and the PARAGON_THEME variable at all?

  • Would it be ok to just have the brand override URLs be configurable for external loading at runtime? In other words, the base Paragon styling would always be loaded.

• How would user theme switching (as in, a user selects between “light” or “dark” in the browser) work without externally loaded CSS (see the open question in the theming howto)? Do we have to have at least the variants exposed as separate entry points?

  • Since the “light” theme is all we have, now, should we care about this now? In other words, is it ok to remove the Paragon entry points?

🎥Recording

• Video: https://drive.google.com/file/d/1xmX2I0q93Ua_pOY9sliFo8M2mVaWkJrc/view?usp=drive_link

• Chat: https://drive.google.com/file/d/1a7IpT9-h6p4htsTN0WDUsYp6LxKbklTz/view?usp=drive_link

• Transcript: https://drive.google.com/file/d/1fhzr5uHiZwnTSfchUVN-88bfX0Nmf2lcmejlC7gGmIU/view?usp=drive_link

 Participants

• Adolfo Brandes

• Brian Smith

🤖 Summary

High-level summary

This Frontend Working Group meeting was primarily about simplifying how Paragon styles/themes are delivered in the new “frontend-base” world, and whether existing mechanisms (CDN-loaded Paragon CSS, version substitution, webpack cache groups/entry points, Paragon webpack plugin, etc.) are still necessary now that frontend-base deduplicates Paragon across microfrontends (MFEs). The group aligned on a direction: remove legacy complexity where possible, keep forward-looking support for theme variants (e.g., future dark mode), and favor runtime-loaded brand/theme overrides over “installing brand packages into every MFE.”

A short second topic covered a proposal about migrating state management: they agreed the goal is no Redux—migrate to React Query or Context/local state.

Key discussion 1: Paragon CSS delivery, CDN URLs, and simplifying frontend-base

1) Should Paragon base styles be loaded from a CDN/external URL?

• Adolfo’s question: does it still make sense to allow loading the full Paragon base CSS (“the whole shebang”, ~500KB) via CDN/external link?

• Brian’s view: generally no, because the original benefit (cross-MFE caching via identical URLs) is largely obsolete under frontend-base, where one Paragon version/package is installed and shared.

• They noted the old approach helped when MFEs could end up on different Paragon versions and needed URL substitution to reduce coupling and manual version syncing.

2) Version substitution (the “Paragon version wildcard”) is likely no longer needed

• Under frontend-base, the expectation is one deduped Paragon version across MFEs (unless someone intentionally forces incompatibility, which would get weird/breaky).

• Adolfo’s goal: remove version substitution, remove Paragon webpack plugin, remove extra entry points and cache groups, and generally reduce config surface area.

3) Runtime theming is still essential (don’t regress)

• Brian emphasized the key user value: change theme/brand by rebuilding only the theme, not rebuilding every MFE.

• They agreed that simplifying bundling shouldn’t break runtime theming; it’s more about where the “base” comes from vs how overrides are applied.

4) The “variants” question (light now, dark later) is the main caveat

• Today there’s effectively a light variant.

• Future: if Paragon supports multiple variants (dark mode, seasonal variants, etc.) and users can switch at runtime, then you cannot load all variants at once.

• That implies variants must remain separately addressable artifacts (so the browser can switch a <link> tag for light vs dark).

• This is the strongest argument for keeping some form of:

  • separate variant outputs (entry points or equivalent), and

  • runtime loading behavior for variants (at least forward-looking).

5) Two acceptable near-term paths (tradeoff acknowledged)

They converged on two “reasonable” approaches for now:

• Pragmatic short-term: keep it simple for launch—bundle Paragon core + current light variant by default, defer multi-variant runtime switching complexity until it’s real.

  • Brian said this is fine for getting frontend-base “out the door.”

• Forward-looking architecture: don’t bake the light variant into the bundle; force variants to be runtime loaded so adding dark later is natural.

They explicitly discussed the risk of removing separation now and needing to reintroduce it later.

Key discussion 2: Brand packages — stop “installing” them into MFEs

• Brian strongly preferred moving away from the current dual-path complexity:

  1. “installed brand package overrides at build time” (npm aliasing etc.), and

  2. “runtime theme URLs”

• Desired simplification: one path for overrides:

  • Paragon is bundled/deduped via frontend-base

  • Brand/theme overrides are CSS variables/overrides loaded at runtime (from a URL)

  • If operators don’t want a public CDN, use tutor-contrib-paragon to build/host theme assets locally (served by Caddy in Tutor)

They agreed this would reduce conflicts and complexity.

Notes on tutor-contrib-paragon mechanics (as recalled in the meeting)

• Themes live under something like: $(tutor config printroot)/env/plugins/paragon/themes

• The directory structure matches variants (light now; dark later).

• The plugin builds/minifies CSS using Paragon CLI and serves static compiled CSS in Tutor, enabling runtime theming without a public CDN.

React Query migration proposal (brief)

• Adolfo raised Tony’s Slack proposal (apparently LLM-assisted) that suggested keeping Redux in some cases.

• Both Adolfo and Brian agreed: No Redux.

  • Migration choices should be: React Query, or Context/local state.

Brian said he would comment on the proposal accordingly (and did during the call).

Decisions / alignment

• Yes: aggressively simplify legacy Paragon theme URL/version-substitution machinery where frontend-base makes it redundant.

• Yes: keep runtime theming as a core capability.

• Likely yes: move away from “install brand packages in every MFE”; treat brand overrides as runtime-loaded CSS.

• Redux: remove entirely; migrate to Query or Context/local state.