vue-router: Errors in lazy loaded components are not propagated and have no source map support

Version

2.7.0

Reproduction link

https://codesandbox.io/s/176k2vp03

Steps to reproduce

  1. Run the codesandbox.io link.
  2. Notice that the component isn’t rendered.
  3. Look at the console to see the unhandled error.
  4. In SSR and on the browser, this error isn’t propagated to the usual error handler. In SSR I tested with renderToString
  5. In SSR the error does not use source maps and is very difficult to debug.

More info

When using VUE Router Lazy Loading, and there’s an error outside of the component, the error is not propagated & the stack trace isn’t cleaned up with source maps. Here’s the gist of the minimal reproduction (linked):

e.g. MyComponent.vue

<script>
throw new Error('bad_error');

export default {
  name: 'MyComponent'
};
</script>

createRouter.js

const MyComponent = () => import('./MyComponent.vue');

export default createRouter() {
  return new Router({
    routes: [
      { path: '/', component: MyComponent }
    ]
  });
}

Error in the logs:

[vue-router] Failed to resolve async component default: Error: bad_error
[vue-router] uncaught error during route navigation:
 Error: bad_error
     at Object.exports.modules.Array.concat.Object.defineProperty.value (0.server-bundle.js:12842:7)
     at __webpack_require__ (server-bundle.js:27:30)
    at Object.<anonymous> (0.server-bundle.js:12708:141)
     at __webpack_require__ (server-bundle.js:27:30)
     at Object.exports.modules.Array.concat.Object.de

What is expected?

I expect the error to be propagated to the renderToString err in the callback and the error to be rewritten using the source maps.

What is actually happening?

When rendered with SSR, the page hangs, as the error is never propagated to renderToString’s err in the callback.

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Comments: 15 (6 by maintainers)

Most upvoted comments

@nemtsov this was the polyfill that was added if you need something that will easily blow up in node 😃 https://github.com/jimmywarting/FormData

To echo @mikesherov: the work that you’re doing on Vue @posva is amazing and is greatly appreciated. This library, like others in the Vue ecosystem is reliable and a pleasure to work with because of the work that you do.

I now see how confusing this issue is without a complete and proper repro; which I’m working on and will post here. The issue that motivated me to report this is with this code in SSR. Using renderToString(app, (err, html) => you expect either to get html or to get an err. When you get an err (provided you have source-maps enabled) the err stack is cleaned up to show the actual line-numbers, file and function names.

The issues we are seeing are:

  1. The err in renderToString does not get called when there’s an import-time error, neither does the callback. This is really bad because there’s no way to handle such an error gracefully. Ultimately, either the browser times out or the user gives up and closes the tab.
  2. The second issue with this is that if you look in the server logs, the error is there, but there’s no way to trace to the file that threw it because the source-maps are not used to clean up the error.

Once again, I’ll provide a minimal repro with SSR for this.