Repository navigation
Conversation
364f99c to
b6212f2
Compare
size-limit report 📦Compared: 0823bbc (PR test merge using develop at 12757d0) Against: ca4fc32 (develop) · base run #62950
|
de28310 to
47c1f76
Compare
47c1f76 to
d1a7e32
Compare
d1a7e32 to
17f5b0c
Compare
17f5b0c to
ff9f3cc
Compare
7185904 to
0846a80
Compare
0846a80 to
2d31aba
Compare
2d31aba to
d7b1800
Compare
|
bugbot run |
d7b1800 to
1d49365
Compare
|
bugbot run |
1d49365 to
89e93d5
Compare
|
bugbot run |
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 5cbcc07. Configure here.
|
One or more gzipped bundles increased by more than 500 bytes. If this increase is intentional, add the Accept Bundlesize Increase label to this PR to rerun and accept the check. |
Optional E2E testsSome optional checks were not successful. They do not block the merge. 1 not successful, 63 successful. See the run.
Successful checks
|
Lms24
left a comment
There was a problem hiding this comment.
Nice! Just had one question about the base path plugin. Once that's resolved, good to merge! Handling tunnel requests directly via our sentryHandle handler seems fine to me.
I guess a future improvement could be to add an option in our sentrySveltekit plugin that auto-enables the managed tunnel on client and server (somewhat similar to the one-option tunnelRoute approach in NextJS) so that users don't have to configure it in two places. But totally fine with not doing this for the moment. In agentic times we might not even need this.
There was a problem hiding this comment.
m/q: can we use makeGlobalValuesInjectionPlugin instead? This should already have the kit config and it already injects other global values. Might be missing a reason though why this plugin makes more sense standalone
There was a problem hiding this comment.
I prefer to keep it as a separate plugin since this needs to work on both server and client files. The existing one works on server files only, so we would be switching logic based on the environment. The existing plugin is only added when source map upload is on as well.
It is doable, but this current one was the simpler approach.
…he app's base path `sentryHandle` answers tunnel requests before isolation, tracing and routing. `sentrySvelteKit()` hands `paths.base` to the client and server SDKs, so `tunnel: true` works under a base path without repeating it.
The tunnel handler now answers a request without one with a 411.
…, in one test per app
…ests of what the SDK adds
…dules as side-effect free
isaacs
left a comment
There was a problem hiding this comment.
A couple of concerns worth addressing before landing, but nothing major, imo.
| }; | ||
|
|
||
| applySdkMetadata(opts, 'sveltekit', ['sveltekit', 'node']); | ||
| applyTunnelBasePath(opts); |
There was a problem hiding this comment.
applyTunnelBasePath reads the global once, inside init. The global is set only when one of three files imports the virtual module first: the hooks files and src/instrumentation.server.*. If the server SDK starts in any other way, the server's managed tunnel has no base path. Examples are node --import ./instrument.server.mjs build with the Node adapter, an init in a module that the build doesn't transform, or a custom server. The browser then posts to /app/<hash>. Kit lets the request reach sentryHandle, but the server matches only /<hash>, so Kit answers 404. The browser falls back to sending directly. Users lose the tunnel without any error or log.
#25408 solved the same problem for TanStack with setManagedTunnelDefaults({ basePath }) from @sentry/core/server. That helper applies the base path to the current client and to every client created later, whenever init runs. Two SDKs in the same stack now pass the base path to the server in two different ways.
Suggestion: on the server, call _INTERNAL_setManagedTunnelDefaults({ basePath }) when sentryHandle() is created. sentryHandle() is always called from the hooks file, after the virtual import has set the global. The per-request Cloudflare clients and a late init would then get the base path too. Keep applyTunnelBasePath for the browser only. This also removes the server and Cloudflare calls to applyTunnelBasePath.
| */ | ||
| export function applyTunnelBasePath(options: Pick<Options, 'tunnel'>): void { | ||
| const basePath = (GLOBAL_OBJ as { [TUNNEL_BASE_PATH_GLOBAL]?: string })[TUNNEL_BASE_PATH_GLOBAL]; | ||
| options.tunnel = applyTunnelDefaults(options.tunnel, { basePath }); |
There was a problem hiding this comment.
e7224db passes any relative string through applyTunnelDefaults. In the browser, tunnel: '/tunnel' with paths.base: '/app' now posts to /app/tunnel. Before this PR it posted to /tunnel. A user whose tunnel lives outside Kit (a reverse proxy, a CDN worker, or a separate service on the same host at /tunnel) silently breaks on upgrade. A user who wrote /app/tunnel keeps working. I verified that stripBasePathFromTunnelPath removes the duplicate prefix.
On the server, a relative string is already a managed-tunnel path after #25199, so the server change follows from the base PR. The browser change is new.
Suggestion: add the base path only for tunnel: true and object forms, and leave explicit browser strings as the user wrote them. If you keep the current behavior, call it out in the changelog as a change for users with paths.base and a relative tunnel.
There was a problem hiding this comment.
Called from packages/sveltekit/src/client/sdk.ts line 27
| .map(escapeStringForRegex) | ||
| .join('|'); | ||
| // oxlint-disable-next-line sdk/no-regexp-constructor -- not end user input + escaped anyway | ||
| entryFileRegexp = new RegExp(`/(?:${hooksFiles}|src/instrumentation\\.server)\\.(?:js|ts|mjs|mts)$`); |
There was a problem hiding this comment.
The regex requires /<hooks path>.(js|ts|mjs|mts)$. Kit's resolve_entry also accepts a directory with an index file, like src/hooks.server/index.ts. Kit's moduleExtensions option can also add other extensions. In those cases the import is not prepended. The existing makeGlobalValuesInjectionPlugin (packages/sveltekit/src/vite/injectGlobalValues.ts line 71) uses /${serverHooksFile}(.(js|ts|mjs|mts))? without an end anchor, so it does match the directory form. The two plugins now target the same files with different rules.
Suggestion: share one matcher between the two plugins, and make it accept the /index.<ext> form. Fixing the comment on packages/sveltekit/src/server/sdk.ts line 30 also makes the server side robust to a missed match.

Implements sveltekit tunnel wiring, the way it works is:
kit.paths.base) if it exists to both server/client bundles.sentryHandle) will check for any incoming request if it is a tunneled one, and if it matches it handles it.(I made the decision to respect base paths rather than ignoring them, this is something to review in #25199)
This also adds a couple of shared e2e helpers to
@sentry-internal/test-utilsthat the rest of the stack uses. Thesveltekit-3tunnel variants cover dev and prod, and there's one for Cloudflare Workers too.For reviewers: if you need an overview of what this is, refer to #25199.
closes #20256