Source map support to trace production errors
gauravbordoloi opened this issue · 5 comments
I am using Sentry for error monitoring and I want to get a proper stacktrace to fix production issues.
With bytenode enabled, I am unable to generate source maps.
Sentry throws the below exception
(vite:bytecode plugin) Sourcemap is likely to be incorrect: a plugin (vite:bytecode) was used to transform files, but didn't generate a sourcemap for the transformation. Consult the plugin documentation for help
Any solution to generate source map? Or this is never possible?
I' also very curious if this is possible @OsamaAbbas - it will be of a great help for debugging issues, specially with sentry indeed.
I' also very curious if this is possible @OsamaAbbas - it will be of a great help for debugging issues, specially with sentry indeed.
The first comment of this issue is clear that the error comes from vite:bytecode plugin (not bytenode). In this page (from their website), it's mentioned that their implementation is only "inspired" by bytenode with some differences. So, maybe you should open an issue in their repository as well.
That being said, I remember that I could implement source map generation previously (two years ago or so). I don't remember how exactly I did it though!
It was probably something like this: we know that the dummy code is just a string or a series of empty characters, with no \n. So, the idea was to correctly minimize the code (before compiling) to make it one long line. We then generate the source map, then we compile the code. I don't remember if this was the exact order of the process. Also, I don't remember how, during running the .jsc file, we would indicate where is the corresponding source map for the .jsc file.
I found the old comment with some details on how to implement source maps (from 2020).
Source maps would be very cool! Though we should certainly default to disabling them… and explaining to people clearly why they might want to keep them disabled.
Source maps would be very cool! Though we should certainly default to disabling them… and explaining to people clearly why they might want to keep them disabled.