Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Time

Item

Presenter

Notes

<5 minutes

Design tokens update

https://github.com/openedx/frontend-build/pull/546

Merged! 🎉 First officially merged contribution towards supporting design tokens 👏

10-15 minutes

Navbar and FPF?

Brian Smith

  • https://github.com/openedx/frontend-component-header/issues/521#issuecomment-2278330431

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

✅ Action items

  •  

⤴ Decisions

...