-
Notifications
You must be signed in to change notification settings - Fork 129
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
build: fix peer depends and update common depends #615
build: fix peer depends and update common depends #615
Conversation
Thanks for the pull request, @ghassanmas! Please note that it may take us up to several weeks or months to complete a review and merge your PR. Feel free to add as much of the following information to the ticket as you can:
All technical communication about the code itself will be done via the GitHub pull request interface. As a reminder, our process documentation is here. Please let us know once your PR is ready for our review and all tests are green. |
2f734e3
to
5e5b8b0
Compare
@ghassanmas Thank you for your contribution, I kicked off the checks. |
@natabene Tests should be resolved now I have run them on the fork. Also apply for other PRs in profile and gradebook |
Codecov ReportBase: 39.50% // Head: 39.50% // No change to project coverage 👍
Additional details and impacted files@@ Coverage Diff @@
## open-release/nutmeg.master #615 +/- ##
===========================================================
Coverage 39.50% 39.50%
===========================================================
Files 106 106
Lines 2187 2187
Branches 582 582
===========================================================
Hits 864 864
Misses 1238 1238
Partials 85 85 Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
@davidjoy Would you be able to review this one, or point me to who should? |
"@fortawesome/fontawesome-svg-core": "1.2.36", | ||
"@fortawesome/free-brands-svg-icons": "5.15.4", | ||
"@fortawesome/free-regular-svg-icons": "5.15.4", | ||
"@fortawesome/free-solid-svg-icons": "5.15.4", | ||
"@fortawesome/react-fontawesome": "0.1.16", | ||
"@tensorflow-models/blazeface": "0.0.7", | ||
"@tensorflow/tfjs-converter": "1.7.4", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This bumps these tensorflow libs through two major versions - do we know that we've absorbed the breaking changes in them and that this won't break?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These are not really used directly, I have researched the code and they are just there as peer depends of @tensorflow-models/blazeface 0.0.7
which require those exact versions hence. That being said, if something would break it would more likely to have broken before.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One change request and one sanity check on some of the version bumps.
package.json
Outdated
@@ -91,5 +91,8 @@ | |||
"react-test-renderer": "16.14.0", | |||
"reactifex": "1.1.1", | |||
"redux-mock-store": "1.5.4" | |||
}, | |||
"peerDependencies": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this is a meaningful change. frontend-app-account is not a package that gets installed as a dependency of anything else, and so can't have peer dependencies for a dependent to install. Further, we don't actually depend on bootstrap to my knowledge.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Paragon depends on it. And by default npm would install the latest version (i.e. boostrap is not pinned in paragon 19.14.1
. So If you try to install then build the app on a the latest npm 8 version. the build would would fail.
The point why I am using paragon 19.14.1
beacuse this the version frontend-app-learning is using, and the point is to have a consistant version of depends across MFEs that are used in openedx release.
Now the question is if frontend-app-learning (nutmeg master) is using paragon 19.14.1 why the build is not failing there? I can specualte that because at the time pacakge-lock.json was updated boostrap 4.6.1
was the latest. Or may be some other depends of learning require that exact version....
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Anyway if you checkout to fronted-app-learning (nutmeg branch) amd run npm ls bootstrap
you should get 4.6.1.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
MFEs can't have peerDependencies - they're not a package that gets installed as a dependency. I don't know if somehow adding peerDependencies removes a warning or something, but I don't think that's the right way to solve whatever problem we're seeing.
It should not matter if MFEs have consistent versions of paragon - the code isn't shared anyway, I don't think it's meaningful to optimize for a consistent version. We shouldn't limit an MFEs version of a library because a different, independent MFE is at a particular version, that's not how the system was designed/intended to be used.
If we need to update these dependencies for nutmeg for some reason, we should just update them to latest - artificially pinning them at earlier versions is only going to cause problems and confusion later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
MFEs can't have peerDependencies - they're not a package that gets installed as a dependency. I don't know if somehow adding peerDependencies removes a warning or something, but I don't think that's the right way to solve whatever problem we're seeing.
The end goal is to force to use a spesfic verion of bootsrap, and I force to do so because otherwise it would break the build. I think it would be doable to have the same result if I instead moved it to deps instead of creating per depnds.
It should not matter if MFEs have consistent versions of paragon - the code isn't shared anyway, I don't think it's meaningful to optimize for a consistent version. We shouldn't limit an MFEs version of a library because a different, independent MFE is at a particular version, that's not how the system was designed/intended to be used.
Again the pinned vresion would resolve the failed build because the artificial created version of boostrap after updarading paragon will result in failed build. When I was debuggin this, I was confused, such that why the paragon update made the build to fail while the same version is being in learning and it builds okay. This made me further debugging the depends of paragon between the learning and other MFEs what I found is that boostrap version is different in the learning thus I tried pin boostrap version, rebuild again and the result was ok.
If we need to update these dependencies for nutmeg for some reason, we should just update them to latest - artificially pinning them at earlier versions is only going to cause problems and confusion later.
I agree that the right path would be frequently update depends for each MFE (Note: I am referring to the open release branches). The thing is its hard to know which version suppose to be compitable with open-release, so my stratgey is find the maximum version of all MFEs and consider that the right version.
Add to that for paragon for example the version is already pinned so artificially updaing the depends is not possible, a different startgey would be to go check the change-log of paragon version 19.* and find if there is any breaking changes and if not, then use the last minor version of paragon 19. which in this case is 19.25.3
So in summary; Assuming using paragon 19.25.3 wouldn't require us to pin boostrap and assuming MFEs would work as epxected using that version. Would you accept such change? (To MFEs nutmeg branch, learning, account profile and gradebook)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@davidjoy even using the latest minor version of paragon 19 didn't resolve it.
Anyway I stumbled upon this issue while checking paragon openedx/paragon/pull/1562 it seems the way to resolve to include the new varriable of bootsrap and if an MFE is using older paragon the solution was to pin it just as I did here ref commit in paryment mfe The difference is that they don't add it per rather direclty in depends.
However I went over npm docs, and the right way to do is to define overrides
I am now testing with overrides and see if build would success and then I willl deploy the same version in production to see if it would also would as expected
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tested and worked as expcted.
To test in production you can go: https://apps.edx.gsgapp.io/account you can use admin@zaat.dev and "zaatdev" as pass.
Bootsrap 4.6.2 cause build to fail due to missing variable: ref: openedx/paragon/pull/1562
@ghassanmas there are some snapshots failing and local development server is not working with following error:
Please pull latest code from master, this error is due to old version of webpack, which is being updated in frontend-build. |
@abdullahwaheed just pushed a fix, by overrideing webpack-cli version hence webpack/webpack/issues/15951 . Also note this error already exists in nutmeg.master. |
Update packages to remove security vulnerabilities (openedx#605) * fix: updated vulnerable packages * fix: fixed failed tests after package update * fix: linting issues failing ci tests * fix: package lock update * fix: snapshot updated to UTC * fix: missing dependency 'long'
f52688a
to
b1c0124
Compare
Secondaly for the tests I have backported 0527c73 and seems to resolve the failing tests |
@ghassanmas Are we sure that |
That chagne is backported to from 0527c73 to fix the failed tests. |
Reviewers, how are we feeling about this? Any further changes requested? (@davidjoy, do you want to hand off final say to somebody else? Who owns the Account MFE, these days?) |
Also, @ghassanmas, do you mind commenting on openedx/wg-frontend#140 so I can assign it to you? Or maybe you can assign yourself, not sure. :) |
@arbrandes I don't I can, but I have just comment there my perspective/finding on that. |
Hi @arbrandes and @ghassanmas! Just checking to see if this is still being pursued? If so, can it be reviewed/merged? |
@ghassanmas @arbrandes friendly ping on this :) |
@mphilbrick211 I think it's fine to close it, since I don't think we support nutmeg releases anymore. |
Ok, closing! |
@ghassanmas Even though your pull request wasn’t merged, please take a moment to answer a two question survey so we can improve your experience in the future. |
fix peer depends and update common depends