Problem Statement
@sentry/solidstart cannot be used with SolidStart v2. The v2 line is at 2.0.0-rc.10 and upstream has just exited changeset pre-mode (solid-start#2279), so a stable release looks close.
v2 drops vinxi for plain Vite plus Nitro v3, and removes app.config.ts entirely. Against @sentry/solidstart@10.69.0 that breaks three ways:
- Peer dependency.
"@solidjs/start": "^1.0.0", so every v2 install is a peer conflict.
withSentry has nothing to wrap. It takes the v1 app.config.ts object and reaches into solidStartConfig.server, solidStartConfig.vite and server.modules. In v2 solidStart() is an ordinary Vite plugin, there is no server key, and Nitro v3 takes nitro.plugins rather than v2 modules registering a rollup:before hook.- No
default export condition. The export map declares only browser and node. On a non-Node server runtime the package fails to resolve at all, so a Cloudflare Workers build cannot even import it.
I noticed #22816 added an optional SolidStart 2 E2E app and its description says the SDK is "very vinxi-oriented" and would need changes. I could not find an issue tracking that work, so this is one to point at.
Solution Brainstorm
- Widen the
@solidjs/start peer range to include ^2.0.0.
- Replace
withSentry with a Vite plugin, since that is the only integration surface v2 offers. The source map and release-injection work withSentry does today would move into it.
- Register server-side instrumentation as a Nitro v3 plugin under the top-level
nitro.plugins key.
- Add a
default condition to the export map so non-Node runtimes resolve.
Additional Context
Point 3 matters beyond Cloudflare. v2's default output targets Nitro presets, several of which are not Node, so the missing default condition will bite more than one deployment target.
For anyone blocked today, @sentry/solid plus @sentry/cloudflare in a hand-written Nitro plugin works on Workers. It gives up the automatic source map upload and server entry instrumentation that withSentry handled, so @sentry/vite-plugin has to be wired up directly and build.sourcemap and nitro.sourcemap both named explicitly, because nitropack v2 used to default the latter and Nitro v3 defaults it off.
Possibly related: #13762 on nitro source maps.
Problem Statement
@sentry/solidstartcannot be used with SolidStart v2. The v2 line is at2.0.0-rc.10and upstream has just exited changeset pre-mode (solid-start#2279), so a stable release looks close.v2 drops vinxi for plain Vite plus Nitro v3, and removes
app.config.tsentirely. Against@sentry/solidstart@10.69.0that breaks three ways:"@solidjs/start": "^1.0.0", so every v2 install is a peer conflict.withSentryhas nothing to wrap. It takes the v1app.config.tsobject and reaches intosolidStartConfig.server,solidStartConfig.viteandserver.modules. In v2solidStart()is an ordinary Vite plugin, there is noserverkey, and Nitro v3 takesnitro.pluginsrather than v2 modules registering arollup:beforehook.defaultexport condition. The export map declares onlybrowserandnode. On a non-Node server runtime the package fails to resolve at all, so a Cloudflare Workers build cannot even import it.I noticed #22816 added an optional SolidStart 2 E2E app and its description says the SDK is "very vinxi-oriented" and would need changes. I could not find an issue tracking that work, so this is one to point at.
Solution Brainstorm
@solidjs/startpeer range to include^2.0.0.withSentrywith a Vite plugin, since that is the only integration surface v2 offers. The source map and release-injection workwithSentrydoes today would move into it.nitro.pluginskey.defaultcondition to the export map so non-Node runtimes resolve.Additional Context
Point 3 matters beyond Cloudflare. v2's default output targets Nitro presets, several of which are not Node, so the missing
defaultcondition will bite more than one deployment target.For anyone blocked today,
@sentry/solidplus@sentry/cloudflarein a hand-written Nitro plugin works on Workers. It gives up the automatic source map upload and server entry instrumentation thatwithSentryhandled, so@sentry/vite-pluginhas to be wired up directly andbuild.sourcemapandnitro.sourcemapboth named explicitly, because nitropack v2 used to default the latter and Nitro v3 defaults it off.Possibly related: #13762 on nitro source maps.