/
2025-12-18 Frontend Working Group Meeting Notes: CI and npm OID, frontend-base runtime configuration

2025-12-18 Frontend Working Group Meeting Notes: CI and npm OID, frontend-base runtime configuration

 Date, time, location

 Discussion topic(s)

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

🎥Recording

 Participants

Brian Smith, Adolfo Brandes, Diana Villalvazo Salas

🤖 Summary

What was covered

  1. Paragon releases: move to OIDC + update semantic-release

  • Brian walked through changes to the GitHub Actions release workflow to use OIDC (OpenID Connect) for npm publishing instead of older credential approaches.

  • They added an explicit permissions block (contents/issues/pull-requests/id-token) so the workflow can: create GitHub releases, comment on PRs, and request an ID token for OIDC.

  • They pinned semantic-release to a major version and bumped to a newer version that supports OIDC (also aligned with supported Node versions). The prior pin existed due to Node 18 constraints.

  • They merged and watched CI run end-to-end (build/test/docs) before publishing.

Outcome: The Paragon workflow successfully published 23.18.2, created the GitHub release, and the npm page showed a “built and signed / provenance” indicator tied back to the GitHub Actions run.

  1. frontend-base release strategy + npm “latest” tag issue

  • Adolfo has been manually publishing frontend-base (npm version + npm publish) and noticed npm “latest” wasn’t updating as expected—likely due to prerelease tagging behavior.

  • They investigated npm dist-tags and concluded the practical fix is to manually set dist-tags (e.g., npm dist-tag add <version> latest) so installs without @alpha don’t miss the intended version.

  • Longer-term: prefer automated publishing via semantic-release (like Paragon), publishing prereleases to an alpha channel until ready for stable releases.

Key decision points discussed:

  • Whether to stay on 1.0.0-alpha.x vs switching to 0.x “zero mode” to make “latest” behave more naturally.

  • If/when adopting semantic-release for frontend-base, it should be able to continue from the current prerelease sequence (e.g., alpha.8 → alpha.9).

  1. Runtime config direction for frontend-base + microfrontends

  • Main goal: enable runtime-configurable external routes/URLs (example: learner dashboard header linking to profile and account MFEs).

  • Today: frontend-base uses “roles” and predefined internal config; the group needs a way to set those external routes at runtime via configuration.

They explored where translation should happen:

  • Strong preference: frontend-base should not parse MFE_CONFIG directly.

  • Instead, create a single JSON endpoint that returns config in the format frontend-base expects.

  • That endpoint can internally read existing MFE_CONFIG and translate/aggregate server-side.

Important nuance: MFE_CONFIG can be global and/or per-MFE. To avoid missing MFE-specific settings, the translation endpoint can “act as” specific MFEs for certain config keys when assembling the final JSON. This keeps the client request to one JSON fetch, even if the server performs multiple internal lookups.

Implementation direction:

  • Build the translation as an edx-platform plugin (not baked into core), to support a transition period and be removable later.

  • For Tutor: likely not enabled by default—Tutor could instead generate and serve a static JSON—but the plugin remains useful (including for site-config-related needs).

Ownership:

  • Brian: focus on the frontend-base side (loading mechanism, dev workflow for hosting/editing the JSON during development).

  • Adolfo: start on the backend plugin that generates frontend-base-shaped JSON from MFE_CONFIG.

  1. Instructor dashboard upgrade (Diana)

  • Diana plans to take the Instructor Dashboard frontend-base alpha.8 upgrade work in the coming weeks.

  • Adolfo pointed her to the authn PR and key gotchas:

    • frontend-base now built on Node 24 (regenerate lockfile with clean install).

    • Don’t import Paragon Sass in MFEs anymore; shell loads CSS, MFEs should rely on design token variables / app Sass.

    • Watch for Sass @extend changes and lint rule changes (notably a nullish-coalescing lint rule that had to be disabled in at least one case).

Decisions / Agreements

  • ✅ Proceed with OIDC-based release workflow changes (confirmed working on Paragon).

  • ✅ Adopt/aim toward semantic-release automation for frontend-base; in the meantime, fix “latest” via npm dist-tags when publishing prereleases.

  • ✅ Runtime config should come from a single frontend-base-friendly JSON endpoint, translated server-side, ideally shipped as an edx-platform plugin.

  • ✅ Split work: backend translation plugin (Adolfo), frontend-base loading + dev UX (Brian).

Action items

  • Brian

    • Investigate frontend-base runtime config loading + a good dev story for editing/hosting the JSON config locally (e.g., with frontend-platform / dev server).

    • Implement support for runtime-configured external routes (profile/account/logout links, etc.).

  • Adolfo

    • Start design/implementation of an edx-platform plugin that reads MF config and emits a frontend-base-formatted JSON config endpoint.

    • Decide how the endpoint handles MFE-specific overrides while still producing one unified config payload.

  • Adolfo (near-term operational)

    • When manually publishing frontend-base prereleases, set/update npm dist-tags so latest points where intended.

  • Diana

    • Take instructor dashboard upgrade: bump frontend-base + related dependencies, align with Node 24, remove Paragon Sass imports, address lint/type updates.