Open kpelelis opened 5 years ago
I would expect that your build process would include a source map url inline in the code, which would be fetched as needed by the browser and updated natively as your code hot reloads, without needing to do any hijacking of errors.
Problem is, the bundle will never reach the browser:
--> Browser requests page (e.g. /home) --> Hypernova Ruby Client (needs to partially render a div with hypernova, so it requests hypernova for a render) --> Hypernova (tries to render the component and gets and error, so it returns the error) --> Hypernova Ruby Client (renders the error generated from nova) --> Browser renders the HTML page generated
Indeed we have source map generated (with webpack)
Gotcha - and in this case, the client render doesn’t take over?
If by take over, you mean handling the stack trace the answer is no. The Ruby Client knows nothing of the original javascript bundle that the error came from. The idea was to transform the source map in the hypernova server
@ljharb For example, the backtrace displayed on the browser is something along the lines of:
"ReferenceError: idontexist is not defined",
"at new SampleComponent (ssr.bundle.js:35348:5)",
"at processChild (ssr.bundle.js:34431:14)",
"at resolve (ssr.bundle.js:34397:5)",
"at ReactDOMServerRenderer.render (ssr.bundle.js:34724:22)",
"at ReactDOMServerRenderer.read (ssr.bundle.js:34695:25)",
"at Object.renderToString (ssr.bundle.js:35109:25)",
"at ssr.bundle.js:11566:46",
"at /home/dev/node_modules/hypernova/lib/utils/BatchManager.js:190:18",
"at tryCatcher (/home/dev/node_modules/bluebird/js/release/util.js:16:23)",
"at Promise._settlePromiseFromHandler (/home/dev/node_modules/bluebird/js/release/promise.js:512:31)"
Note that:
ssr.bundle.js
) is loaded by hypernovaapp/assets/javascript/foo.js:3
Could it be that rolling our own implementation (with vm.runInNewContext()
) instead of using createGetComponent
is messing up the source maps?
Thanks!
Gotcha. So you do have a source map for that bundle, you just want it somehow applied in the hypernova error.
That does seem like something that could be done inside hypernova itself. However, perhaps if you included https://www.npmjs.com/package/source-map-support yourself, it would be handled for you?
Yeah! We already tried that by pre-pending the snippet required by source-map-support in the bundle with the help of webpack. Problem is, runInNewContext messes up the line offset so the source map is sort of invalid.
We finally got a solution going with a rather hacky way. Instead of using a webpack dev server and loading the module over http in hypernova server, we run a normal webpack server with —watch and we load the bundle from the file system. In this way we can employ all the cool features of hypernova without any custom code. We still need to pre-pend the snippet though, but it works just fine.
If it is okay with you, we can patch the server so that a user, or a plugin can handle errors.
In any case, thanks a lot for looking into it.
Cheers, Skroutz team
It's hard for me to really understand the scope of this without a PR. Would you be willing to make one, with the understanding that there's no promise to merge it? If it's reasonable and doesn't seem to add much complexity, I'm sure it'd be fine, but I want to set your expectations appropriately :-)
Hello. In order to speed up our development process, we have build a custom solution for the hypernova server which can load Javascript bundles over HTTP. With that, we can spin up a webpack dev server and reload the compiled bundle each time the source files change. That has been working wonders for the time being and we are really happy that we don't have to compile the files over and over again.
In order to make development even better, we wanted to add source map support for the generated stack traces. Our current implementation is the following.
1) Client asks for component
Foo
2) We load the code for componentFoo
over the webpack dev server 3) We evaluate its code withvm.runInNewContext
and we catch any errors generated 4) Should we catch any error, we load the source map file and we feed it into asourceMapConsumer
from Mozilla's source-map. 5) We then map all the stack trace elements into new ones by querying the consumer. 6) Finally we throw the modified error.Code would look something like this
Although this works great for the time being, we wanted to catch "runtime" errors as well. That is, errors generated when (e.g.
ReactDOM.renderToString
runs). To my understanding, there is no way to manipulate such errors fromBatchManager.render
as the exceptions are caught and modified there.We could submit a patch upstream to enable custom error handling if there is no other elegant way of manipulating error traces.