chore: do not fixStacktrace

[benmccann]

Description

Closes #7528

Users should call ssrFixStacktrace themselves when catching an exception. This avoids issues with that method possibly being called multiple times

This fixes the playground examples, which all currently have broken exception handling because they all call vite && vite.ssrFixStacktrace(e). That is invalid because Vite currently calls that method internally and so it ends up being called twice which breaks the stack traces

Additional context

For Vite 3.0 since this is a breaking change

---

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

Before submitting the PR, please make sure you do the following

• Read the Contributing Guidelines.
• Read the Pull Request Guidelines and follow the Commit Convention.
• Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
• Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
• Ideally, include relevant tests that fail without this PR but pass with it.

[DylanPiercey]

Wouldn't it be better to remove all of these stack trace fixing api's and just fix sourcemap support for dev mode ssr? #3288

[benmccann]

Wouldn't it be better to remove all of these stack trace fixing api's and just fix sourcemap support for dev mode ssr? #3288

Sourcemaps work for the browser, but the stack trace fixing APIs are helpful when printing an exception to the console. If we did want to go in that direction though this PR would still be a helpful step

[DylanPiercey]

Right, nodejs also supports sourcemaps specifically for the purpose of fixing the stack trace: https://nodejs.org/dist/latest-v18.x/docs/api/cli.html#--enable-source-maps

I believe the vite dev server should be updated to always enable source map support in node since it can be enabled programmatically and it'd make this transparent to the end user.

[benmccann]

Ah, interesting. Thanks for sharing! I wasn't aware of that.

I think this PR would be a good step to take given that. It stops fixing stack traces so that people can either use that flag or manually fix the stack trace using the Vite-provided APIs. Then people can experiment and make sure that the flag works just as well for all the various frameworks. I have some concern that having to specify a flag on the CLI is less user-friendly, but with this PR each framework would have the option to try which ever method they expect would work best and we can get feedback from the ecosystem community

[DylanPiercey]

I have some concern that having to specify a flag on the CLI is less user-friendly

Right, I agree. However it can be enabled manually and I was suggesting vite would just do that by default in dev mode (https://docs.nodejs.org/api/process.html#processsetsourcemapsenabledval)

[patak-dev]

@benmccann we talked about the change with the team. Let's disable fixStacktrace by default. We think that we should still keep the feature as opt-in though, for users currently using it. At one point in the future, we could start issuing a deprecation warning if we want to remove the complexity.
@DylanPiercey thanks for the pointer to --enable-source-maps, definitely worth looking to check if we should enable it by default. As @benmccann said, disabling fixStacktrace by default is a needed step if we go there.

[benmccann]

Thanks @patak-dev for the review and discussing with the team. I've updated this PR accordingly