feat(tanstackstart): Add @sentry/tanstackstart-react package and make @sentry/tanstackstart package a utility package

[lforst]

I realized thanks to TanStack/router#3607 (comment) that TanStack Start is gonna be a generic thing that supports multiple frameworks like React and Solid (maybe even more in the future).

This means that we should probably not publish the package for TanStack Start React as @sentry/tanstackstart. I thought about doing submodule exports like @sentry/tanstackstart/react and @sentry/tanstackstart/solid but that comes with a few (user-facing) drawbacks that I don't want to deal with:

• We don't know how well submodule exports behave with all the build tooling.
• Intellisense is going to show stuff from all the different submodule exports which is extremely error-prone and may break apps if you accidentally import the wrong thing, maybe leading to super opaque errors.

For the reasons above I decided to make the @sentry/tanstackstart package a utility package that we can use to host generic instrumentation helpers and publish an additional package called @sentry/tanstackstart-react that contains the actual SDK. For now the utils package is empty but that will change in the future as we see fit.

[Lms24]

LGTM! No strong opinions on own package vs. subpath export. I think the reasoning for having @sentry/tastackstart-react it as its own package makes sense, though it's a bit unfortunate that we need more than one package for the framework (related, see my Q about the @sentry/tanstack package).

Other nits (feel free to ignore):

• let's add the package(s) to the main README in the repo
• let's update the bug report issue template s.t. users can select the package

[Lms24]

should this rather be @sentry-internal/tanstackstart then? Or are we planning on instructing users to install both packages?

[lforst]

I had thought the same, I opted to do it like this for now because I messed up because I already published the package, so it's out there and grabbing SEO. We definitely need to update the README for the package that's out there for now, so I think this is still fine - maybe I'll deprecate the package and go for the internal name in a future PR. Hope that makes sense. I wish I hadn't published the package already 😂 😭

[chargome]

Will the framework support using multiple ui libs within one app at some point e.g. like Astro? Then specifically naming the package would cause confusion in the future

[lforst]

Will the framework support using multiple ui libs within one app at some point e.g. like Astro? Then specifically naming the package would cause confusion in the future

I don't think so. Also we need specific instrumentation APIs, so even if, I think this split would make sense.