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

Support source maps in qx.log.appender.Native #9487

Open
cboulanger opened this Issue Jan 26, 2018 · 3 comments

Comments

Projects
None yet
2 participants
@cboulanger
Contributor

cboulanger commented Jan 26, 2018

Currently, when using the new compiler error stack traces are from the compiled/transpiled sources. The compiler generates source maps, so we should use those. I am not familiar at all how that works, however.

@johnspackman

@johnspackman

This comment has been minimized.

Member

johnspackman commented Jan 26, 2018

This is possible but raises practical issues - the source maps are 1Mb in size just for a tiny demo app, and I have several real world apps that are 5Mb; source maps would have to be downloaded by the client and parsed in order to map to the original line numbers. It could cause issues with memory, CPU, and app startup times; maps can be downloaded on demand to avoid startup time issues, but this would mean server round trips at a time when there could be very unpredictable errors in the system.

Two solutions:

Client Mapping

(a) source maps on the client are enabled in config.json as off, on-demand, or preloaded;
(b) if the maps are not yet downloaded (ie on demand), the errors are always output to the client console untranslated, with a note that they are not mapped; if the maps are downloaded successfully the updated error map can be output after the original

Server Mapping

provide a command line qx command that, given a copy & pasted version of the exception log, can rewrite it with mapped line numbers. This would be useful for build targets where the source files would typically not be available for debugging during production anyway, and the developer would have to retrieve the diagnostics data from the client's logging area anyway.

However, in order to successfully parse the error output, it would have to be normalised across browsers. AFAICR the output varies in what's available to output at certain times as well as the format it is displayed in; note that the Global Error handler gets information which can be noticably different to ordinary exceptions

@cboulanger

This comment has been minimized.

Contributor

cboulanger commented Jan 26, 2018

What about a new qx.log.appender.QxServe which would work together with qx.serve and query source map data from this server asynchronously?

@johnspackman

This comment has been minimized.

Member

johnspackman commented Jan 26, 2018

ah yes, good idea - I have a log appender that ships logs to the server already, so I could repurpose that. There will still need to be some work to normalise the exception log output but that shouldn't be too hard

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment