fix(nextjs): parses the nextjs router correctly

[dohooo]

Before submitting a pull request, please take a look at our
Contributing guidelines and verify:

• If you've added code that should be tested, please add tests.
• Ensure your code lints and the test suite passes (yarn lint) & (yarn test).

Fixes #12256

Background

Description

In case to increase the complexity of the original regex. I've added a new parser to handle the specific scenario of Next.js routes.

The core concept is to replace the key characters of Nextj.js routes as encoded characters. For example:

.../app/[locale]/sentry-example-test/(default)/sub/page-xxxxxxx.js:11:11
to 
.../app/%5Blocale%5D/sentry-example-test/(default)/sub/page-xxxxxxx.js:11:11

Why did I choose this way?

Because the original parser always split this stack line to

{
  ...,
  function_name: ".../app/[locale]/sentry-example-test/",
  filename: "default)/sub/page-xxxxxxx.js"
}

But the correct results should be

{
  ...,
  function_name: undefined,
  filename: ".../app/[locale]/sentry-example-test/(default)/sub/page-xxxxxxx.js"
}

And I found the original parser is too complex to extend. So I create a new parser to handle this scenario and made it more proprietary and explicitly used for nextjs routing.

Did I test it?

Yes, I've tested it with the following cases:

1. This logic will affect the most of the users using nextjs and sentry. So I've modified the original tests to integrate the nextjs parser to ensure that everything works well as before, even though user aren't using nextjs.
2. I've added a new test to handle specify cases from nextjs.

[AbhiPrasad]

Thank you for the PR!

[dohooo]

Can I get a review for this PR?

[AbhiPrasad]

the stacktrace parsing seems reasonable to me, but I'd like to get @lforst opinion as our resident Next.js expert.

[lforst]

Thanks for the PR, however, I think this is a bit of a bandaid solution and we should instead fix the parsing logic in the chromium stack trace parser.

Started working on fixing the regex instead: #12373

[dohooo]

Thanks for the PR, however, I think this is a bit of a bandaid solution and we should instead fix the parsing logic in the chromium stack trace parser.

Started working on fixing the regex instead: #12373

If u want to update the chromium stack trace parser means that if Nextjs update their routes rules, u should to update this complexity regex. I think this isn't a good solution, because not all frameworks will have logic similar to Nextjs. Why should we increase this complexity to the global level and use it to handle all situations? Splitting it is the right way to reduce complexity. Otherwise, these parses should be refactored asap.

[dohooo]

If u want to handle more in the top-level parser. U also need to pay attention about the expo-router. I believe there are some similar framework custom routes, and it may be a better solution to spread them into different packages for processing. hope you can consider

[lforst]

I think this isn't a good solution, because not all frameworks will have logic similar to Nextjs.

The reason this bug exists is because our chromium stack trace parser has a bug for frames that are in the global module scope and contain parentheses. See this (currently) failing test case. It absolutely makes sense to fix this in the core module.

I fully agree with you that the regex is too complex and we should replace it with a state machine parser. That thing is 4+ years old.

[dohooo]

It absolutely makes sense to fix this in the core module

Ah understand, thx for your explanation.

[dohooo]

Is this PR still needed?

[lforst]

Is this PR still needed?

No I think we fixed it in #12373. Thank you for the effort though! Much appreciated!