feat: improve type accuracy for getConfig() and others#874
Conversation
|
Thanks for the pull request, @bradenmacdonald! This repository is currently maintained by Once you've gone through the following steps feel free to tag them in a comment and let them know that your changes are ready for engineering review. 🔘 Get product approvalIf you haven't already, check this list to see if your contribution needs to go through the product review process.
🔘 Provide contextTo 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:
🔘 Get a green buildIf one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green. DetailsWhere 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:
💡 As a result it may take up to several weeks or months to complete a review and merge your PR. |
4127108 to
e655da2
Compare
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #874 +/- ##
==========================================
+ Coverage 87.14% 87.85% +0.70%
==========================================
Files 48 50 +2
Lines 1408 1482 +74
Branches 300 296 -4
==========================================
+ Hits 1227 1302 +75
- Misses 168 169 +1
+ Partials 13 11 -2 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
e655da2 to
0970425
Compare
|
@arbrandes @dcoa could you take a look at this please? I need this to fix some errors encountered when upgrading the version of frontend-platform used in the Authoring MFE. |
| * @param {Object} newConfig | ||
| */ | ||
| export function mergeConfig(newConfig) { | ||
| export function mergeConfig(newConfig: Partial<ConfigDocument>) { |
There was a problem hiding this comment.
When we initialize an application or add new configuration for a component we pass string as scope in the mergeConfig function
As you can see here
- https://github.com/openedx/frontend-app-authoring/blob/master/src/index.jsx#L185
- https://github.com/openedx/frontend-component-header/blob/master/src/Header.jsx#L31
I just wonder if should we add it as a optional parameter (and pass it to the publish if is set)
There was a problem hiding this comment.
I see what you mean, but I'm not sure what to do with that string value and I don't really want to change any runtime behavior in this PR, so I've just left it for now.
|
Can we also export the react-intl types (
I tested in local and have |
arbrandes
left a comment
There was a problem hiding this comment.
Only have an inline suggestion, but otherwise, can't find anything to object to.
Good catch. Fixed :) |
Description:
Quick follow-up to #868 to improve the types, for MFEs using
frontend-platform.How to test locally
package.jsonto work aroundsemantic-releasewarnings/annoyances:npm run buildforfrontend-platformfrontend-component-header, editpackage.jsonlike so:npm install, then test the code, e.g. runnpm run typesMerge checklist:
frontend-platform. This can be done by runningnpm startand opening http://local.openedx.io:8080.module.config.jsfile infrontend-build.fix,feat) and is appropriate for your code change. Consider whether your code is a breaking change, and modify your commit accordingly.Post merge: