Potentially use Stacklyn for stack parsing to reduce maintenance overhead

[doctoon]

Problem Statement

As pointed out in #4543 , stacktrace parsing is hard to maintain and get right.
As of this issue it looks like your latest commit was related to stack parsing so I thought this was the perfect time to chip in.

While building this, I did a bunch of research into the internals of the most common stacktrace formats to make sure things stay accurate.
(I even tested on Firefox lol)

Solution Brainstorm

I present to you... 🥁
Stacklyn!

It can parse any JavaScript stack trace from Chrome, IE, Firefox, Espruino, etc :D
It has zero dependencies, and supports parsing, converting, source mapping, stringifying back from an object, and more!
It took a little over 2 months but I think it would be a great fit for Sentry.

If you want to check it out, the github is at https://github.com/stacklynjs/stacklyn 😊
It's actively maintained (currently I'm the only one but whatever) too unlike most other parsers I came across (they're still awesome tho)

Would love your thoughts and criticism, I'm happy to help or adapt Stacklyn to your structure if you're interested!

[linear]

JS-831 Potentially use Stacklyn for stack parsing to reduce maintenance overhead

[Lms24]

Hey @doctoon thanks for writing in! I think this is a really cool project you started here. However, I'm afraid we'll not switch to it in the future. There are a couple of reasons for this:

1. Most importantly, we have a strict "avoid dependency cost" policy for our SDKs. This comes from years of experience with dependencies. I don't want to insinuate that you're not maintaining your package well enough! However, we'll likely need to fix or change stuff and this will take longer than if we maintained the code directly. So at some point, we'd need to fork or vendor in your code, like we do for example with Google's web-vitals library, several OpenTelemetry instrumentations or rrweb.
2. Related to this: Error monitoring is our bread and butter and hence, stack trace parsing is one of the most critical code paths. We definitely want to own this part. With very few exceptions and edge cases, our stack parsers have been fairly stable for the last years.
3. I took a quick look at your repo and wanted to leave some notes on why I think in the current state, even without reasons 1 and 2, we couldn't use it:
   • There are no tests in this repo. With all the intricacies of stack parsing, I'd expect a lot of them. Unit and on integration test level (e.g. with Playwright for browsers or actual node processes)
   • We're extremely cautious about bundle size and I'm fairly sure that the Stacklyn code footprint is larger than our stack parsers. For example, most of the logic is contained in a class. Classes cannot be treeshaken by bundlers, so there's no way to reduce the footprint by eliminating the code we don't need.
   • In general, it looks like this library tries to combine Node API usage with browser code, which is very problematic. Even if you're try/catching Node API usage, it adds unnecessary weight to browser code for stuff that will never run. We therefore have specific stack parsing logic, that's applied to our Node or Browser SDKs. In addition, none-Node compatible server runtimes (Cloudflare, Vercel Edge, etc) will likely also need special handling.

I hope this outlines our reasoning well. Please don't see it as insult but rather as some pointers on what I think would make this library better. Again, super cool project you picked!