-
Notifications
You must be signed in to change notification settings - Fork 57
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: capture plugin errors during ready
phase
#5681
Conversation
This pull request adds or modifies JavaScript ( |
eventName: string, | ||
featureFlags: FeatureFlags, | ||
) => { | ||
if (!featureFlags.netlify_build_plugin_system_log) { |
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 failed to mention this on the last PR, but I think this flag should be called netlify_build_plugin_system_log_errors
or similar. The current name makes it sound like it's related to #5391. Having said that, the flag is super short-lived, so it shouldn't matter too much.
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.
Yeah, I totally see that. Let's hope we can kill the flag soon.
return { childProcess } | ||
} catch (error) { | ||
if (featureFlags.netlify_build_plugin_system_log) { | ||
// Wait for stderr to be flushed. | ||
await pSetTimeout(0) |
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.
would setImmediate
also work here?
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.
It would, yes. Just trying to stay as conservative as possible with this change.
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 change looks good. Left some small comments. I'll play around locally to see if I can write a test for the ready
event.
Summary
Follow-up to #5679. Extracts the logic for registering and unregistering the listeners into a separate method, which is now called for both the
load
and theready
phases of the plugin initialisation.Sadly I cannot write a test that asserts the behaviour for the
ready
phase because I can't find a way to produce that locally. Since we use the same method asload
, our existing tests gives us some coverage.