Better stacktraces when using SolidJS via a library?
Whenever an error occurs within a SolidJS component library, the stacktraces are extremely cryptic. I'm building the library via tsup-preset-solid
I've got
"sourceMap" is enabled in the tsconfigGitHub
GitHub - solidjs-community/tsup-preset-solid: Preset for building y...
Preset for building your SolidJS packages with tsup. - GitHub - solidjs-community/tsup-preset-solid: Preset for building your SolidJS packages with tsup.
4 Replies
I don’t see what’s the issue
the fact that they are all pointing to a single file?
or that it’s not a source .ts file?
tsup doesn’t support source maps for declaration files
but it should be possible to have source maps for .js files
idk if it helps though
basically every error within the library throws with this same stacktrace, so the stacktrace becomes unusable in helping to pinpoint where the error is.
handleError is somewhere within solidjs' internal ownership-related code
getting the source .ts file would be the ideal for sure, but even getting a stacktrace of the built js would be a massive improvementexpanding the stack trace does nothing?
if solid is catching and throwing the error in a different place, it doesn’t seem like it has anything to do with it happening in a library
the pic from above is the expanded stacktrace 🥲
could it be an issue with the safari devtools on mac? i can't confirm for sure, but i believe i'm seeing a complete stacktrace for the same error on my windows machine