docs: Add Deno import example for Supabase integration

[cursor]

DESCRIBE YOUR PR

Addresses user feedback from docs.sentry.io (DOCS-ANT).

• Added a Deno-specific configuration section to the Supabase integration page showing the correct npm:@sentry/deno import before the Supabase import
• The existing snippet (for non-Deno platforms) is preserved unchanged under a PlatformSection notSupported guard
• Fixed a minor typo in the Configuration section intro ("most use cases. and" → "most use cases and")

IS YOUR CHANGE URGENT?

• None: Not urgent, can wait up to 1 week+

PRE-MERGE CHECKLIST

• Checked Vercel preview for correctness, including links
• PR was reviewed and approved by any necessary SMEs
• PR was reviewed and approved by a member of the docs team

  

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
develop-docs	Ready	Preview, Comment	May 7, 2026 4:45pm
sentry-docs	Ready	Preview, Comment	May 7, 2026 4:45pm

[sergical]

@cursoragent we have a pattern for dynamically importing the right version of the SDK import in other places, can we do that instead of just doing the Deno SDK? That snippet has a Sentry.init in it, so we need all configurations for the supabase integration to also import Sentry from the SDK package for the platform this page is being served on

[cursor]

• Implemented: Updated the Supabase integration docs to use our dynamic SDK import pattern.
• Change: Non-Deno block now imports Sentry via the platform-aware placeholder; Deno keeps the explicit npm import.

Code reference:

import * as Sentry from "___SDK_PACKAGE___";
import { createClient } from '@supabase/supabase-js';

const supabaseClient = createClient('YOUR_SUPABASE_URL', 'YOUR_SUPABASE_KEY');

Sentry.init({
  dsn: 'YOUR_DSN',
  integrations: [
    Sentry.supabaseIntegration({ supabaseClient })
  ],

Status: Committed and pushed to cursor/docs-feedback-processing-500d. The Deno section continues to use import * as Sentry from 'npm:@sentry/deno' before other imports.

• Added dynamic ___SDK_PACKAGE___ import to ensure Sentry.init resolves the correct SDK per platform.
• Preserved and clarified the Deno-specific snippet using npm:@sentry/deno (first import).

  

[sergical]

@cursoragent do we need the specific deno callout to yield the two separate platform includes blocks, feels redundant, no?

[cursor]

Short answer: yes — we need the Deno-specific block.

Reason:

• The dynamic placeholder (SDK_PACKAGE) resolves to @sentry/deno, but Deno requires the npm: prefix (npm:@sentry/deno).
• Deno also needs npm:@supabase/supabase-js, which differs from other platforms.

Because our current placeholder system doesn’t add npm: for Deno, a single unified snippet would be copy/paste-wrong for Deno. Keeping two minimal PlatformSection blocks ensures both variants are correct and ready to paste.

If you want to de-duplicate, we’d need a new placeholder (e.g., SDK_IMPORT_PATH and SUPABASE_IMPORT_PATH) that renders with npm: for Deno. That’s a small infra change but out of scope for this PR.

  

[cursor]

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 9c0689c. Configure here.}

[sergical]

Closing in favor of #17673 which fixes the root cause — ___SDK_PACKAGE___ now resolves to npm:@sentry/deno on Deno pages, so all snippets get the correct import automatically without per-page workarounds.