-
Notifications
You must be signed in to change notification settings - Fork 3k
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
feat(ui): bump frontend dependencies #8353
feat(ui): bump frontend dependencies #8353
Conversation
00898c6
to
70761c0
Compare
Hey @ngamanda - so sorry for the delay on this review. I'm pulling down the code now and going to do a little test drive with it and then start reviewing shortly after. There's a coupe conflicts, but I'll do my local testing rebased on master. |
datahub-web-react/.eslintrc.js
Outdated
'no-console': 'off', | ||
'no-debugger': 'warn', | ||
'require-await': 'warn', | ||
'@typescript-eslint/no-explicit-any': 'warn', |
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 think my preference here would be to try to make this upgrade as transparent as possible, for now. While it's more ideal to fix a lot of these, doing this in stages where we upgrade with the warnings=off, and then can address one at a time. Helps keep the changeset a bit smaller. Also keeps the console build warnings smaller. Again, I know it's sweeping under the rug in the short term, but I'd rather not have to make every yarn start
show a ton of warnings.
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.
Sure, I'll swap all the warnings to off then. You mentioned you tried rebasing locally - will you be updating this MR with the resolved conflicts or should I tackle that instead?
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 guess more specifically if you could set the warnings to match what the eslintrc had before, that would be great 👍 Not sure if they all really need to be necessarily off if we had some to warn before, thinking to keep parity unless there's a reason we can't do that.
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 won't be able to directly edit this PR due to permissions, so if you can do that here that would be ideal.
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.
The good news is CI passed on my test branch, so I'm gonna plan to do a bit more testing on it today. Then once that's feeling good, we can figure out a time to merge. One thing about this kind of PR is that it can lead to some interruption on developers side so we may want to do a little announcement or something that folks need to re-yarn / upgrade node ideally post-merging this.
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.
But we can handle that post-merge of course
datahub-web-react/build.gradle
Outdated
@@ -16,7 +16,7 @@ node { | |||
} | |||
|
|||
// Version of node to use. | |||
version = '16.8.0' | |||
version = '16.20.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.
Thank you so much for this!
@@ -1,8 +1,11 @@ | |||
/* eslint-disable @typescript-eslint/no-var-requires */ |
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.
Nice, this kinda stuff for webpack upgrades is really tricky to figure out 🙏
70761c0
to
0ee1e09
Compare
@ngamanda I'm noticing the analytics tab's charts x axes values look wrong they appear to be numeric, and I'm guessing it's trying to format a timestamp as a number instead of a date. Could you take a look at that? |
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.
Setting to changes requested due to the x-axis issue on the charts.
Hey @joshuaeilers, thanks for catching that! Just committed a fix - lmk if there's any other issues! |
30686b1
to
31a6532
Compare
This is looking good to me. Tagging in @chriscollins3456 in for the final review and discuss merge timelines. I know we have a couple fairly critical frontend changes coming in this month so we may want to schedule this in October for stability sake, but I'll defer to Chris on that. Thank you again so much for this work! |
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 is looking great! I pulled it down and built everything from scratch and it's looking good to me. the changes make sense and I think this is going to resolve a good amount of our vulnerability issues with older versions of packages as well. thanks so much for this @ngamanda !
I'm going to double check with the team before merging but I think we're close to good to go here
configure: { | ||
optimization: whenProd(() => ({ | ||
splitChunks: { | ||
cacheGroups: { | ||
vendor: { | ||
test: /[\\/]node_modules[\\/]/, | ||
name: 'vendors', | ||
chunks: 'all', | ||
}, | ||
}, | ||
}, | ||
})), | ||
// Webpack 5 no longer automatically pollyfill core Node.js modules | ||
resolve: { fallback: { fs: false } }, | ||
// Ignore Webpack 5's missing source map warnings from node_modules | ||
ignoreWarnings: [{ module: /node_modules/, message: /source-map-loader/ }], | ||
}, |
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.
nice I'm excited about this! hopefully reduces our build size a bit
'no-unsafe-optional-chaining': 'off', | ||
'prefer-exponentiation-operator': 'off', | ||
'prefer-regex-literals': 'off', | ||
'react/destructuring-assignment': 'off', | ||
'react/function-component-definition': 'off', | ||
'react/jsx-no-bind': 'off', | ||
'react/jsx-no-constructed-context-values': 'off', | ||
'react/jsx-no-useless-fragment': 'off', | ||
'react/jsx-props-no-spreading': 'off', | ||
'react/no-unstable-nested-components': 'off', | ||
'react/require-default-props': 'off', |
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.
so these lint changes were necessary as we bumped dependencies we had new linting rules being applied that we didn't want applied?
nothing I'm seeing is concerning to me just wanted to call it out
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.
Yeap! That's right 😃
@ngamanda thank you so much again! just merged in latest and then pulled and ran locally again and we're looking good to go. going to merge now! |
a9650b6
into
datahub-project:master
There's a whole bunch of lint warnings now. I'm setting them to
warn
for your review. Let me know if you'd prefer to turn them off or just bulk update them.yarn.lock
@vs
packages to@visx
@data-ui/xy-chart
to@visx/xychart
moduleNameMapper
to map packages rather than transpiling them againChecklist