2023-07-12 Meeting notes

Owned by Gabriel Weinberg, created
Last updated: Jul 12, 2023
3 min read

 Date

Jul 12, 2023

 Participants

  • @Gabriel Weinberg

  • @Adam Stankiewicz

 Goals

  •  

 Discussion topics

Time

Item

Presenter

Notes

Time

Item

Presenter

Notes

 

Tree shaking & Paragon

@Adam Stankiewicz

Recent issue was identified/reported with relatively large implications around performance: Compound component (e.g., `Form.Group`, `SearchField.Advanced`) exports include entire module in Webpack bundles · Issue #2425 · openedx/paragon

tl;dr; Importing a single compound component (e.g., Form.Group) from Paragon means the resulting application bundle that gets shipped to the user includes all Paragon code, not just the code related to Form.Group, leading to unnecessarily large JS bundle sizes.

Examples:

Compound component: Form.Group

Standalone component: FormGroup

Some potential ideas for next steps:

  • Try to find a workaround to make tree shaking work with compound components (not sure this is possible).

  • Verify all compound components in Paragon also can be imported as a standalone component.

  • Update documentation to suggest only using standalone components.

  • Deprecate and eventually remove compound components, or do we support both and have consumers be the deciding factor in whether that want to use the tree shakable components or not.

  • Create a codemod / CLI tool to automatically migrate from compound → standalone components.

  • Anything else that might need to be addressed?

Notes:

  • Consider documentation pointing only to the optimized documentation, but add a warning for compound components slated for depr

  • Avoid depr process out of the gate

  • More IDE friendly for compound components

  • Keeping compound components generally is user friendly for engineers

  • Tree Shaking and compound components should work together in some way

 

Ensuring @edx/brand-openedx is the default brand package committed in code

@Adam Stankiewicz

[context] Semi-regularly, an issue is raised that the @edx/brand-edx.org NPM package is installed by default in a repository within the openedx GitHub organization.

@edx/brand-edx.org is 2U/edX specific and should not be committed in code within openedx. 2U/edX and other instances apply the @edx/brand-edx.org package as an NPM alias override through internal configuration.

Some proposed ideas:

  • Surface the installed brand package and its version across all consuming packages of @edx/paragon in the “Usage Insights” tool. For example, something like:

  • Update the “Usage Insights” automation to auto-create a GitHub issue when it detects something other than @edx/brand-openedx is installed in a consuming project.

  • Standardize and include NPM scripts in package.json files in consuming projects for running MFEs locally with a custom @edx/brand package that doesn’t get committed in code.

    • Example: THEME=@edx/brand-edx.org npm run start:with-theme as a possible usage API where the package specified in the THEME environment variable is installed with --no-save.

  • Modify fedx-scripts in @edx/frontend-build in some way to prompt users to optionally specify a custom @edx/brand package when running npm start and/or npm run build.

  • Any other ideas to better enforce only installing @edx/brand-openedx in code and improve the developer experience for running/building MFEs locally with custom themes?

Related issues:

Notes:



Autosuggest stuff

@Brian Smith

`Form.Autosuggest` error states and freeform text · Issue #1732 · openedx/paragon

Form.Autosuggest Accessibility · Issue #2410 · openedx/paragon
browser autocomplete (just turn it off?)

 

Notes:

  • Disable the tooltip (autocomplete="off") and see if there are any issues on the a11y side.

  •  

 Action items

Try to find a workaround for compound components and tree shaking

 Decisions