-
Notifications
You must be signed in to change notification settings - Fork 11
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
deps: upgrade to esbuild #327
base: main
Are you sure you want to change the base?
Conversation
This stack of pull requests is managed by Graphite. Learn more about stacking. Join @shakyShane and the rest of your teammates on Graphite |
6b1de33
to
dcb10ef
Compare
85c79f6
to
792dae9
Compare
3adce5b
to
f2fd5e4
Compare
3d7f66a
to
7207a7b
Compare
276c9a7
to
0590e7a
Compare
0590e7a
to
791d2d4
Compare
|
||
// don't allow tests to run until the background page is ready | ||
if (context.backgroundPages().length === 0) { | ||
await new Promise((resolve) => context.on('backgroundpage', resolve)) | ||
} |
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 solves the flakiness with the extension tests. Sometimes the background page is already spawn, sometimes not. This ensures we never proceed with it
Rebased on |
👋🏻 @sjbarag - thanks for checking in on this. I made more progress during the last 'quick wins' and the very final 'blocker' was a performance regression on very large DOM counts. My theory is that because of the way esbuild is more aggressive with hoisting modules during the bundling phase, I think more codepaths are hit than would be otherwise. That, or the memory overhead from the eager evaluation of the hoisted modules could be causing it too. For reference, it was something like 50ms over a page with 1000 inputs, so actually wasn't a worry so to speak. But since that was discovered at the very end of the last quick wins, we decided not to press the button. I now think that was a mistake, and that any kind of perf hit here would never materialize in reality (we have lots of checks in place to prevent it). IMO, if the rebased version of this still works on all platforms (eg: spinning them up for a sanity check) then I'd be confident to merge this and move forward. @GioSensation would you tend to agree - feels like a plaster we need to rip off :) |
@shakyShane thanks for the context! TBH I didn't do any manual testing (just the existing unit/integration suites), so I can't comment on whether there's any noticeable perf regressions. |
I wasn't able to reproduce any performance issue whatsoever, even with the unrealistic page. Not quite sure what we were seeing back then. We can resolve the conflicts, sanity check on all platforms, and merge 🎉. @sjbarag will you do the honor? |
And just to celebrate, besides the more modern tooling, better DX, and faster build time, the new output files are ~21% smaller than the old ones. 🚀 Thank you Shane for the original PR and Sean for resurrecting the convo. |
Thanks @GioSensation - this is a nice step forward. For more context too, the following none-SERP projects all use esbuild now
🥳 |
@sjbarag Please hold on merging this. We may need an urgent fix for Android and I'd rather avoid adding risk at this stage. I'll let you know later today or tomorrow. |
Reviewer: @GioSensation
Asana:
Description
npm start
) in case you want it. Personally I just let the build script before playwright run because this is so fast, but there might be situations when working in native, where you'll want to build on every file changeSteps to test