2024-08-14 Meeting notes

<5 minutes

Design tokens update

feat: add `ParagonWebpackPlugin` to support design tokens by dcoa · Pull Request #546 · openedx/frontend-build

Merged! First officially merged contribution towards supporting design tokens

10-15 minutes

Navbar and FPF?

@Brian Smith

• Allow Header Customization via Frontend Plugin Framework · Issue #521 · openedx/frontend-component-header

• What do we need out of the Navbar component to support consumers using frontend plugin framework?

  • Is the entire header a plugin slot? Yes. Support wholesale replacement.

  • Also defining plugin slots within the default/base header itself.

    • E.g., customize without needing to replace entire header.

  • Does it make sense to use Navbar from Paragon?

    • Navbar is from Bootstrap.

    • Navbar likely should support the same slots supported by the proposed plugin slots.

      • Should formalize what slots we want/need.

    • Incremental approach:

      • Introduce slots with what we have today, then extend it further as a follow-up to Navbar.

    • [JeffW] header vs. nav

      • Paragon’s Navbar is nav. The header element would be provided by frontend-component-header.

      • Usage guidelines possibilities in docs site?

    • Brainstorm Navbar contains which slots?

10 minutes

Peer dependency on Paragon in @openedx/frontend-build?

@Adam Stankiewicz

Context:

• There is some forward-looking intent to “go build-less” in JS libraries, where dist would no longer exist. There are several code paths within ParagonWebpackPlugin that expect dist to exist.

• ParagonWebpackPlugin also depends on a specific file, theme-urls.json within the installed @openedx/paragon.

[question/concern] How do we prevent instances that deploy to production from master from causing a regression when upgrading to a version of paragon/brand that no longer contains dist (e.g., buildless) or theme-urls.json (e.g., renamed)?

There could be risk in not properly catching an upgrade of @openedx/paragon (for example) that results in deploying an MFE with no CSS, as it would not throw any errors during build and likely not trigger alerts during monitoring, resulting in a largely unusable app without styles.

Notes:

• @Brian Smith Paragon is already a peer dep in frontend-base

  • frontend-base is taking on the role of frontend-build & frontend-platform (& more!).

• Would adding @openedx/paragon within peerDependencies be an approach to handling this?

  • Pros:

    • Should result in throwing an npm install or npm ci error during local development, if/when there are version incompatibilities.

    • We’re OK with the tight coupling in the forward-looking vision, so doesn’t seem like there’s a concern for coupling Paragon ↔︎ frontend-build.

  • Cons:

    • Introduces coupling that frontend-build must always be used alongside Paragon.

      • Similar to how frontend-platform must always be used alongside @openedx/frontend-build since env.config was introduced.

    • Breaking change.

      • peerDependency SemVer range >=22 < 24

    • Manage yet another peerDependency.

      • frontend-base will mitigate the addtl peerDependency.

  • OPEN QUESTION: who picks up the work/prioritization?

    • Add peerDep, verify it works, communicate out the release.

    • @Adam Stankiewicz will file a GitHub issue to document the task.