log plugin compat #158
log plugin compat #158
Conversation
The `tracing-log` interop layer reports log metadata in a different format, this PR adds handling for these special metadata keys to improve the quality of reported log metadata
Since devtools is incompatible with the log plugin anyway (it serves the same purpose too but better) it would be handy for it to fully replace the log plugin during development. This PR adds the last missing piece of interop with the log plugin by intercepting the JS log messages and emitting them to the same log stream as all other messages.
CrabNejonas
requested review from
lucasfernog-crabnebula,
david-crabnebula,
atila-crabnebula,
tejas-crabnebula and
johann-crabnebula
as code owners
✅ Deploy Preview for cn-devtools-app ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
✅ Deploy Preview for cn-devtools-website canceled.
|
| tauri::plugin::Builder::new("probe") | ||
| // we pretend to be the log plugin so we can intercept the commands | ||
| // this plugin is incompatible with the log plugin anyway | ||
| tauri::plugin::Builder::new("log") |
There was a problem hiding this comment.
I don't really like this.. I feel if someone is using devtools, they shouldn't need the log plugin. We should document that instead (e.g. use the log plugin on production, devtools on development).
There was a problem hiding this comment.
Yes that is the idea, but as stated in the issue #150 devtools misses out the one feature that makes tauri-plugin-log great: the ability to emit logs from both Rust and JS to the same place.
There was a problem hiding this comment.
what do you think about making the log plugin not crash on init? so you can keep using its APIs
There was a problem hiding this comment.
yeah that could work actually
There was a problem hiding this comment.
gonna be difficult though, bc we have to init the log plugin in the setup callback not the builder function
There was a problem hiding this comment.
why does it matter? as long as we tell people to enable devtools first and both register at the same place..
There was a problem hiding this comment.
you mean like this?
tauri::Builder::default()
.plugin(devtools::init())
.plugin(tauri_plugin_log::init())There was a problem hiding this comment.
yeah (plus where we actually register the log plugin)
This adds compatibility with the JS commands from the
tauri-plugin-logby intercepting calls to thelogcommand and emitting them to the unified data stream.This also adds handling for properly displaying the source code location of JS messages if available.
builds on #159
resolves #150 resolves DT-69