search

vuejs / vue

This is the repo for Vue 2. For Vue 3, go to https://github.com/vuejs/core
http://v2.vuejs.org
MIT License
207.94k stars 33.68k forks source link

Add feature to catch errors in a production build for compatibility with external error tracking #11666

Open ssmulders opened 4 years ago

ssmulders commented 4 years ago

What problem does this feature solve?

Currently all warnings are suppressed when Vue is built with process.env.NODE_ENV === production. However, many warnings are more severe than a warning - they break functionality. Duplicate keys are a good example. These are hard to filter out in a development environment because the production data could be different.

I'm currently working on a project where parts of the API and corresponding data are over 15 years old.

This means that when a user triggers an error, we're flying blind. No errors are reported. We recently implemented Sentry (which we already ran for Laravel) but again, no errorHandler or warningHandler is triggered.

What I would have liked was a way for us to see the error in production, but not show it to the user in their console. The error and warning handlers are perfect for this purpose, but lack this feature.

After extensively digging through the code and making alterations I've been able to create a production build that outputs warnings and errors. Without activating development features (like devtools, perf traces etc.) - just the warnings. No loss in performance. But it took tweaking both the Vue core files and the component-compiler-utils.

Still, it's possible, and for us, running Vue at scale, with many unknown variables - it's a must have. With these Sentries (or whatever bug tracker someone would choose) it's easy to quickly zero in on production bugs. So I'd love to improve on our solution, push it to the main repo and give back to your awesome framework :-)

What does the proposed API look like?

My proposal is to add a new process.env variable called DEBUG_LEVEL, WARN_LEVEL or something along those lines. Maybe a config setting. Something simple. With it you can pick your desired verbosity. When set to FULL, it's identical to the development build. When set to HANDLER it will only trigger custom handlers (which would then be where you'd call the Sentry / error tracker). This allows for more granular control over what is triggered, and how it's shown. And then the final setting would be NONE. Which would be identical to the current production build.

Currently the process.env.NODE_ENV controls both the warnings and the debug tools. My proposal is to separate the two.

I've already done most of the leg-work. With your thumbs-up I will clean things up, write tests and push it to the dev branch.

posva commented 4 years ago

This probably should go through a detailed RFC (vuejs/rfcs)

ssmulders commented 4 years ago

Will do. Currently still exploring and mapping the full scope of the issue. Even compile errors get ignored leading to non-functioning output without any feedback. To me, this feels weird. Granted, compile errors will surface in a local dev build. But still, if you run a CI/CD pipeline with a build test (like we do), it undeservedly passes.

ssmulders commented 4 years ago

Still working on this. Another thing I discovered is the lack of warning / debug information on IE11 due to the usage of Proxy. One of the few things you can't polyfill. The errorHandler works, but the warningHandler, doesn't - it's unsupported. Couldn't find any mention of this in the documentation.