feat: add `ParagonWebpackPlugin` to support design tokens

dcoa commented 5 months ago

Description:

This PR updates the original one https://github.com/openedx/frontend-build/pull/365 closer to the master branch and adds some extra tests.

Please read the original PR for additional context.

Changes

Delete Runtime Configuration reference: My reason for making this change is the nature of runtime configuration, which can override any configuration defined previously. The plugin runs during the build time and we have env.config.js that can set the variables. (let me know if my reasoning is correct)
Update @edx/paragon to @openedx/paragon and add compatibility for either @edx/brand or @openedx/brand

Finally, I would like to split this PR in 2 one for the main implementation and another one for the example app (due to this one adds frontend-platform and paragon)

openedx-webhooks commented 5 months ago

Thanks for the pull request, @dcoa!

What's next?

Please work through the following steps to get your changes ready for engineering review:

:radio_button: Get product approval

If you haven't already, check this list to see if your contribution needs to go through the product review process.

If it does, you'll need to submit a product proposal for your contribution, and have it reviewed by the Product Working Group.
- This process (including the steps you'll need to take) is documented here.
If it doesn't, simply proceed with the next step.

:radio_button: Provide context

To help your reviewers and other members of the community understand the purpose and larger context of your changes, feel free to add as much of the following information to the PR description as you can:

Dependencies

This PR must be merged before / after / at the same time as ...
Blockers

This PR is waiting for OEP-1234 to be accepted.
Timeline information

This PR must be merged by XX date because ...
Partner information

This is for a course on edx.org.
Supporting documentation
Relevant Open edX discussion forum threads

:radio_button: Get a green build

If one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green.

:radio_button: Let us know that your PR is ready for review:

Who will review my changes?

This repository is currently maintained by @openedx/committers-frontend-build. Tag them in a comment and let them know that your changes are ready for review.

Where can I find more information?

If you'd like to get more details on all aspects of the review process for open source pull requests (OSPRs), check out the following resources:

When can I expect my changes to be merged?

Our goal is to get community contributions seen and reviewed as efficiently as possible.

However, the amount of time that it takes to review and merge a PR can vary significantly based on factors such as:

The size and impact of the changes that it introduces
The need for product review
Maintenance status of the parent repository

:bulb: As a result it may take up to several weeks or months to complete a review and merge your PR.

itsjeyd commented 5 months ago

Hey @dcoa, thank you for this contribution! Please let us know when the changes are ready for review.

itsjeyd commented 3 months ago

@dcoa We've got a green build here and it's been a while since the last update. So I'm assuming that the changes are ready for engineering review. Let me know if that's not the case.

dcoa commented 3 months ago

Hi @itsjeyd yes, it is ready for review and has been tested alongside other design tokens PRs here https://github.com/openedx/frontend-app-discussions/pull/726

itsjeyd commented 3 months ago

Thanks for confirming @dcoa.

@brian-smith-tcril @adamstankiewicz Would you be able to have a look at this PR?

brian-smith-tcril commented 3 months ago

@dcoa in https://openedx.slack.com/archives/C071U9E4VNV/p1715966767660459?thread_ts=1715940913.033459&cid=C071U9E4VNV I mentioned

I'd prefer to move over to using @openedx/brand-openedx everywhere but I don't remember all of the gotchas/blockers around that. I think moving forward we should try to use @openedx but if we run into conflicts because of it we can alias back to @edx and note why that was required in any given instance.

When I wrote that I wasn't thinking about landing this PR as a non breaking change. Since the plan now is to land this as a non breaking change I think that fully justifies keeping the @edx namespace for now.

I would still like to make the move to the @openedx namespace, but since doing so is a breaking change I feel it would be better off as a separate PR so as to not delay the merge of this one.

adamstankiewicz commented 3 months ago

Thanks @brian-smith-tcril. Only thing I'd add regarding the brand package scope (@edx/brand vs. @openedx/brand) is that I think it might make sense to handle either scope so we are compatible with the current state of MFEs' usage with @edx/brand, but also be forward-looking knowing we will migrate to @openedx/brand eventually. Once we're confident consumers/instances have fully migrated to @openedx/brand, we could come back to remove the @edx/brand at that point. Supporting both scopes now would eliminate the need for any coordinated effort in adding support for @openedx/brand down the road.

openedx-webhooks commented 3 months ago

@dcoa 🎉 Your pull request was merged! Please take a moment to answer a two question survey so we can improve your experience in the future.

openedx-semantic-release-bot commented 3 months ago

:tada: This PR is included in version 14.1.0 :tada:

The release is available on:

Your semantic-release bot :package::rocket:

openedx-semantic-release-bot commented 3 months ago

:tada: This PR is included in version 15.0.0-alpha.15 :tada:

The release is available on:

Your semantic-release bot :package::rocket:

davidjoy commented 2 months ago

I had a comment here about using default as a key name, but I think it's actually fine.

openedx / frontend-build