Commandar Rick - hey @Seve in https://github.c...
hey @Seve
in https://github.com/tscircuit/tscircuit/issues/1542
Based on the error screenshot showing blob URLs in stack traces, this seems like an issue in @tscircuit/eval or @tscircuit/cli.
2 Replies
I'd recommend fixing this in @tscircuit/eval first, since that's where the web worker execution happens and where errors originate. The fix would involve catching errors from the worker and sanitizing the stack traces before they're returned to the caller. We'd use a regex to replace the blob URL portion (everything from blob:http up to but not including the line:column numbers) with something like <webworker> or <anonymous>, so the error would show as <webworker>:263:33 instead. This keeps the useful line and column information while removing the noise. As a secondary measure, we could also add the same sanitization in @tscircuit/cli where errors are displayed in the dev server UI, which would act as a fallback to catch any blob URLs that slip through from other sources. The regex pattern would be something like blob:https?://[^:]+/[^:]+ replaced with <webworker>, which matches the protocol and host/path but stops before the colon that precedes line numbers.
if this sounds good, ill start on this
put up two seperate prs in both
yea something like that makes sense
i wouldn't say that line numbers and the obfuscated text are useful within blob urls but some good tests with
toMastchInlineSnapshot can make it easier for me to assess
i think it is in eval