-
-
Notifications
You must be signed in to change notification settings - Fork 5.4k
fix(nuxt): execute all plugins after error rendering error.vue #32744
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
fix(nuxt): execute all plugins after error rendering error.vue #32744
Conversation
|
WalkthroughThe changes update import paths for several internal Nuxt app types from relative paths using Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Note ⚡️ Unit Test Generation is now available in beta!Learn more here, or try it out under "Finishing Touches" below. 📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
✨ Finishing Touches
🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
@nuxt/kit
nuxt
@nuxt/rspack-builder
@nuxt/schema
@nuxt/vite-builder
@nuxt/webpack-builder
commit: |
CodSpeed Performance ReportMerging #32744 will not alter performanceComparing Summary
|
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 makes sense to me. I think originally this might have been because we wanted to avoid other plugins erroring if they depended on the broken original plugin.
... but as we are already handling an array of errors, I think it makes sense.
maybe we could even move the .catch
to where the promise is defined to avoid duplicating on L448
Done!
We're collecting errors in an array but only throwing the first error on L474, do we plan to make those other errors visible someday? Hiding the errors from plugins depending on a broken plugin makes sense to me though, but (with this change) it's possible unrelated plugins will error too. |
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.
what about we only short-circuit running the plugins if we aren't rendering an error page?
…ugins-after-plugin-failure
2afd278
to
4c0a18c
Compare
sorry for the back and forth! 🤦 hopefully this is still good! |
}).catch((e) => { | ||
// short circuit if we are not rendering `error.vue` | ||
if (!plugin.parallel && !nuxtApp.payload.error) { | ||
throw error |
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.
@danielroe
This should probably be throw e
, right? 👀
🔗 Linked issue
📚 Description
Resolves #32743
This way the order of plugins won't break the setup of unrelated plugins.