Improve Error DX

There have been some comments around error boundaries & general feedback to devs when errors occur.

Here is an example of a plugin with broken code.

module.exports = {
    name: 'netlify-plugin-one',
    onInit: () => {
      console.log(thing.what) // undefined ref
    },
}

or

module.exports = {
    name: 'netlify-plugin-one',
    onInit: () => {
      throw new Error('http://www.nooooooooooooooo.com/')
    },
}

Currently errors materialize like so:

Are there ways we can improve upon this?

[lesliecdubs]

Chiming in to +1 these suggestions! I think it’s imperative we more clearly surface these errors both in the logs and the UI to avoid user confusion and churn, like @jlengstorf said:

new customers may not get that far — they might just contact support and/or churn because “Netlify isn’t stable”

Could we get this work prioritized as part of the #project-build-plugins-ui scope?

Once we know how this is going to work on the backend, it’d be super helpful to get an issue opened in https://github.com/netlify/netlify-react-ui/issues so we can send the UI work through our typical process: design can take these suggestions and formalize a solution, then we can send it into frontend implementation (@drewm will lead that work), Copy Club, etc. 🙂

[jlengstorf]

all makes sense, and I’m on board. A couple wishlist items that I’d really like to see in place to avoid frustration/confusion later on:

1. Make it one-click to remove and rebuild when a plugin fails

• messaging makes it clear when plugins cause a failure, and which plugin caused the failure
• enable/disable provides a quick way to get your builds going again

this makes sense, and I’ll make a request since it sounds like we’re already building all of this functionality:

could we make the uncaught error message say something like this?

There was an unexpected error in the plugin
`netlify-plugin-dont-touch-my-garbage`. As a
precaution, the build was stopped and nothing
was deployed.

BUTTON: **Disable this plugin and rebuild.**

clicking the button would both turn off the build plugin and restart the deploy

2. Log unexpected failures so we can identity broken plugins/opportunities to coach plugin devs

utils.build.failPlugin allows plugin authors to explicitly signal that the build can continue safely even if their plugin fails unexpectedly - we can also shout about this in the plugin authoring docs to encourage it when possible

can we make sure we’re logging the failures in an analyzable way? this would help us flag and remove plugins that are outright broken, and gives us potential to provide actionable feedback to developers (your plugin has X unexpected failures with the message “Y” — consider using utils.build.failPlugin to avoid these failures)