mirror of
https://github.com/supabase/supabase.git
synced 2026-10-06 09:55:06 +03:00
chore/function-recent-errors
12
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Andrew ValleteauandClaude Fable 5.1
|
6fab3bd789 |
fix(studio): keep sharp out of the self-hosted standalone build (#50658)
## I have read the [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) file. YES ## What kind of change does this PR introduce? Bug fix (self-hosted Studio image packaging). ## What is the current behavior? Since the Next 16.3.5 bump, the self-hosted `next build` (`output: 'standalone'`) traces Next's optional `sharp` dependency into `.next/standalone`. Next 16.3.5 upgraded `@vercel/nft` (vercel/next.js#93979), so tracing now follows `module-sync` export conditions, and Next only excludes sharp from the trace when it detects Vercel. Effects: - The self-hosted standalone output carries the `sharp` and `@img/*` native binaries, roughly 10 to 20 percent of the image. - The slim-services Studio image fails: it loads every `.node` file eagerly, and sharp's binary segfaults on linux/amd64 without the matching libvips shared library. `apps/studio` does not depend on `sharp` directly. The last Studio image without sharp in the trace was `2026.09.14`. ## What is the new behavior? Single-file change to `apps/studio/next.config.ts`. When `NEXT_PUBLIC_IS_PLATFORM` is not `'true'`: - `images.unoptimized: true`, so `next/image` renders plain `<img>` and the server 404s `/_next/image` before sharp is ever loaded. This matches what the TanStack build already does via `compat/next/image.tsx`. - `outputFileTracingExcludes` drops `**/node_modules/sharp/**` and `**/node_modules/@img/**` from the standalone trace. Hosted Studio is unchanged: `unoptimized` stays `false`, the exclude key is omitted, and image optimization keeps running on Vercel. Self-hosted CSP is `frame-ancestors 'none'` only, so loading remote avatars directly instead of through `/_next/image` does not hit a CSP rule. Also hoists the existing `isPlatform` const from `redirects()` to module scope. **Why the globs start with `../../`.** Studio builds with Turbopack, which resolves `outputFileTracingExcludes` relative to the app directory. A plain `**/node_modules/sharp/**` becomes `apps/studio/**/node_modules/sharp/**` and never matches the pnpm store hoisted to the monorepo root. Each leading `../` moves the glob root up one level (`relativize_glob` in Next's `crates/next-core/src/util.rs`), so `../../` anchors the pattern at the repo root. The webpack path applies the same globs unprefixed for the server trace, so this is Turbopack-specific. ## Additional context Considered and rejected: a Next.js issue. Next intentionally ships sharp for self-hosted `next start` image optimization and intentionally excludes it only on Vercel. Opting out per app is the supported path. Test plan: - CI: typecheck, lint, Prettier, Studio unit tests, Studio Docker Build. - Verified on this PR with a temporary step in the Studio Docker Build workflow that ran `find` inside the production image for `node_modules/sharp*` and `node_modules/@img*` files. It failed on the first commit (globs rooted at `apps/studio`, image still contained `@img/colour`) and passed once the globs were anchored at the repo root. The step was removed before merge. - Hosted preview should still serve optimized images from `/_next/image`. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01SZHcgqB2qNqCvWsFJ9Qvo8 <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Refactor** * Improved configuration handling for platform and self-hosted deployments. * Self-hosted builds now avoid bundling unnecessary image-processing binaries, while platform deployments retain image optimization support. * Clarified configuration comments. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com> |
||
|
Ivan Vasilov
|
2a75ff7ae6 |
chore: Disable turbopack cache for builds (#50616)
<!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Improved build reliability by disabling Turbopack’s on-disk build cache. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
claude[bot]andClaude
|
3a11d78c6f |
Revert source-map disable from #50579 (re-enable Sentry source maps for studio) (#50581)
<!-- ccr-slack-attribution --> _Requested by **Ali Waseem** · [Slack thread](https://supabase.slack.com/archives/C0161K73J1J/p1789738618897549?thread_ts=1789738618.897549&cid=C0161K73J1J)_ **Before:** #50579 disabled Sentry source-map generation and upload for `apps/studio` (`sourcemaps: { disable: true }` in `apps/studio/next.config.ts`), as a same-day attempt to fix Vercel Preview builds OOMing during compilation. **After:** Sentry source maps are re-enabled for `apps/studio` by removing that option, restoring the file to its exact pre-#50579 state for this line. Disabling source maps turned out not to fix the OOM issue after all — builds still hung. The actual fix was switching Vercel to Elastic Build Machines (an infrastructure setting, not a code change), which brought build times down to ~4 minutes. Since source maps are valuable for Sentry crash visibility and are no longer needed to work around the OOM, this PR re-enables them. Note on scope: `output: 'standalone'` in `apps/studio/next.config.ts` is left untouched by this PR. It was removed and then re-added within #50579 itself (net no change on merge), and it remains present (`output: 'standalone'`) on the current default branch HEAD. Any further discussion about removing `output: 'standalone'` (raised separately in the Slack thread) is intentionally out of scope here. This is a minimal, surgical revert of only the sourcemaps-disable line from #50579 — it does not touch #50578 (an unrelated Next.js/dependency version bump) or any other change. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01UqvBiopu7KUqAkQNvEnkoJ --- _Generated by [Claude Code](https://claude.ai/code/session_01UqvBiopu7KUqAkQNvEnkoJ)_ Co-authored-by: Claude <noreply@anthropic.com> |
||
|
Jordi Enric
|
823d4d0991 |
build: disable sentry source maps for deployment test (#50579)
## Problem Next.js deployments can stall after compilation while Sentry performs post-compile source-map processing. We need a controlled deployment test to isolate that phase. ## Fix Disable Sentry source-map generation and upload for Studio, Docs, and WWW without changing Sentry logging, dependencies, or other build configuration. ## How to test - Deploy Preview builds for Studio, Docs, and WWW. - Confirm each build passes the post-compile phase. - Expected result: the builds complete without running Sentry source-map processing. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Chores** * Updated production build configuration to use the default output mode. * Continued disabling source map handling in production. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Jordi Enric
|
ef527f447a |
chore(studio): enable Sentry build diagnostics (#50474)
## Problem Studio Vercel builds can stall after compilation inside the Sentry production compile hook. Sentry currently suppresses its build output, so the deployment log does not show which operation stalls. ## Change Enable Sentry build diagnostics for Studio platform builds on Vercel by setting silent to false and debug to true. Source-map generation, upload behavior, and runtime reporting remain unchanged. ## How to test - Deploy this branch to the Studio Vercel project. - Inspect the log after Next.js compilation completes. - Confirm that Sentry reports its post-compile progress and exposes the operation that stalls or fails. The diagnostic build may still time out; this change is intended to reveal the cause before applying a workaround. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Chores** - Enabled additional diagnostic logging for platform builds to improve visibility into build-time error monitoring configuration. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
18431efb25 |
fix(studio): TanStack post-merge fixes — Monaco loader, fonts, CSP (from #46424) (#47657)
Post-merge fixes for the TanStack Start migration (#46424) — things that broke on the TanStack build as master evolved under the migration branches. Kept on their own branch off master rather than piling onto the E2E-matrix PR (#47119); all land on master and cascade up to S6 + the big PR. Common theme: a master PR changed something the Next pipeline handles via `next/font` / `pages/_app.tsx` / `next.config.ts`, but the hand-rolled TanStack equivalent (`routes/__root.tsx`, `styles/fonts.css`, `vercel.ts`) wasn't updated to match — invisible on the Next deploy, broken only on TanStack. --- ## 1. Monaco loader path (#47182) #47182 re-nested the served Monaco assets from a flat `public/monaco-editor/` layout into `public/monaco-editor/vs/` and updated `pages/_app.tsx`, but `routes/__root.tsx` still pointed `loader.config` at the old path, so `loader.js` 404'd and **no Monaco editor mounted anywhere in the TanStack build**. Now mirrors the Next config (`${origin}${BASE_PATH}/monaco-editor/vs`, window-guarded for SSR). Was failing the whole `tanstack` E2E shard on #47119. ## 2. Inter + Manrope fonts (#47306) #47306 renamed Tailwind's sans var `--font-custom` → `--font-sans` and added `--font-heading` (Manrope), set via `next/font` on Next. `fonts.css` still only set the now-ignored `--font-custom`, so the body fell back to the theme's system chain (`Circular, custom-font, Helvetica…`) at weight 450 — that's the "Inter weights look wrong". Manrope was missing entirely. - Wire `--font-sans` (Inter) + `--font-heading` (Manrope) to match `next/font`. - **Vendor all three families** (Inter, Manrope, Source Code Pro) via `@font-face` so nothing depends on the Google Fonts CDN — matches `next/font` self-hosting, and (see below) `font-src` doesn't allow `fonts.gstatic.com` anyway. Verified in-browser: computed `body` → `Inter`, headings → `Manrope`, all loading from local `/assets/*.woff2`. ## 3. Security headers / CSP (next.config.ts `headers()`) The Next build sets X-Frame-Options / X-Content-Type-Options / HSTS / **Content-Security-Policy** / Referrer-Policy via `next.config.ts`. The TanStack build never carried these over — `vercel.ts` only set cache-control, so **the deployed TanStack dashboard shipped with no CSP at all**. The TanStack deploy serves a static shell (no server to attach headers), so they go in the Vercel config: - `security-headers.ts` — shared source of truth, reuses `getCSP()`, env-gated exactly like next.config. - `vercel.ts` — apply to every response (all base-path prefixes): full `getCSP()` + HSTS on platform. - `scripts/serve.js` — the non-platform set (`frame-ancestors 'none'`) for the self-hosted server. **Tested the policy in a real browser** (temporarily enforced it on the TanStack build via /test-supabase-local): everything passed except one real gap — `font-src` was missing `data:`, so GraphiQL's bundled Monaco codicon font and Stripe's payment-element fonts (both data: URIs) were blocked (37 violations on a cold load). Added `data:` to `font-src` in `csp.ts` → violations drop to zero, SQL editor Monaco renders clean. That gap affects the Next build too. --- ## 4. `node:path` import crashing `/project/[ref]/merge` Found by a full-site click-through of the TanStack build (all product areas, ongoing — see below). `useEdgeFunctionsDiff.ts` + `EdgeFunctionsDiffPanel.tsx` did `import { basename } from 'path'` in client code. Webpack (Next) polyfills `path` in the browser; Vite externalizes it, so the whole `/merge` route crashed with "Module \"path\" has been externalized for browser compatibility". Replaced the two `basename` call sites with a string helper. Verified in-browser: `/merge` renders. ## 5. URL shape — Next-style search-param semantics + shim fixes The dashboard produced malformed URLs vs the Next build (strange query params, trailing slashes, `##` hashes). Root cause + audit verified empirically against `@tanstack/react-router@1.170.10`; all fixed with unit tests and browser-verified: - **`createRouter` used TanStack's default JSON search codec** — `?flag=true` became `?flag=%22true%22` via links, repeated `?filter=…&filter=…` collapsed into a JSON array (breaking multi-filter/sort table-editor URLs and the account-page round-trip, which double-encoded), and search values arrived as numbers/booleans where the app expects strings. New `lib/router-search-params.ts` (Next-style: strings in, strings out, repeated keys → string[]) wired into the router. - **Link shim** (`compat/next/link.tsx`): `URL.hash` includes the leading `#` while TanStack's `hash` prop adds its own → every `href="…#section"` navigated to `##section` (hash-scroll broke); `Object.fromEntries(searchParams)` dropped repeated query params. Both fixed. - **Trailing slash injected before the query** on every `?`-only relative navigation (`/auth/providers/?provider=…`): fixed in the compat router (prefix current pathname) and via a custom nuqs adapter (`lib/nuqs-tanstack-adapter.tsx`) replacing the stock tanstack-router adapter, whose `navigate({ to: '?…' })` writes hit the same TanStack behavior (123 files use nuqs). - **Pathname-less `router.push({ query })` leaked path params** — Next re-consumes `ref`/`id` from `query` into the path pattern; the shim didn't, yielding `/editor/17597?schema=public&ref=<ref>&id=17597&filter=…` from table-editor filter/sort, linter panels, and advisor shortcuts. The shim now defaults the pathname to the current route pattern and backfills omitted params. - **Redirects dropped query + hash** (Next's `redirects()` preserves them): `__root.tsx` `matchRedirect` and `routes/index.tsx` now carry incoming params/hash through (consumed rule params excluded, destination's own params win). `/?next=new-project&projectName=zzz` → `/new/new-project?projectName=zzz`; `/sql/quickstarts?template=x#frag` → `/sql/examples?template=x#frag`. Browser-verified post-fix: advisors `?preset=WARN`, providers `?provider=Google`, `?schema=auth` — all clean (no `/?`, no leaks); repeated `filter` params survive hydration; `=true` unquoted; single `#`. ## 6. TanStack `navigate` corrupting query values (Logs Explorer SQL newline loss) TanStack router-core treats a query string embedded in `navigate({ to })` as part of the *path*: `decodePath` percent-decodes it and `sanitizePathSegment` strips control characters, silently deleting every `%0A`. Logs Explorer's SQL (`s` param) lost its newlines on Run/reload — `order by timestamp desc` / `limit 5` glued into `desclimit 5`, which then failed the LIMIT lint. Pre-existing on the TanStack build (the stock nuqs adapter had the same shape); Next unaffected. Fixed by never embedding query strings in `to`: the nuqs adapter and the compat `router.push`/`replace`/`prefetch` (plus the `next/navigation` shim) now pass search as an object through the app codec (`splitInternalUrl` hoisted to `lib/internal-url.ts`). Guard test drives a real `createRouter` with multi-line SQL through both producers. Browser-verified: newlines survive the full Run → reload → re-Run cycle. ## 7. Integration overview markdown never loaded (all integrations) `MarkdownContent` used a template-literal dynamic import (``import(`@/static-data/integrations/${id}/overview.md`)``) — webpack builds a context module for that, Vite can't analyze it, so every integration detail page threw `Failed to resolve module specifier` and rendered no overview text. Fixed with an explicit lazy registry of literal imports (`static-data/integrations/overviews.ts`, drift-guarded by a test) plus an `mdRawLoader()` Vite plugin mirroring next.config's turbopack raw-loader rule. Both runtimes keep working; md stays out of the main bundle. ## 8. GraphiQL editor never mounted (`exports is not defined`) Our `umdAmdShortCircuit()` Vite plugin (which disarms Monaco's global AMD loader for deps like papaparse) rewrote `typeof define === 'function' && define.amd` to `false` inside `monaco-editor`'s bundled copy of marked — whose UMD relies on its own *local* `define` shim — so the whole optimized monaco chunk failed to evaluate and GraphiQL's editor pane stayed blank. The check now only short-circuits when `define` is the global AMD loader. Browser-verified: all four GraphiQL Monaco panes mount, queries execute. (Known follow-up: GraphiQL's Monaco workers fall back to the main thread under Vite — functional, worker wiring is Next-specific `setup-workers/webpack`.) ## 9. `@sentry/nextjs` bundling Next internals — built TanStack bundle crashed (caught by E2E) The E2E suite against the **built** TanStack bundle (not the dev server) found lazy chunks like `table-editor-*.js` dead on arrival: `@sentry/nextjs` (imported by ~25 client files) drags in `next/dist/shared/lib/constants`, whose module scope evaluates `process?.features?.typescript` — optional chaining doesn't guard an undeclared `process` in the browser, so the whole chunk failed at load with `ReferenceError: process is not defined`. Dev shims `process`, which is why weeks of dev-server testing never saw it. Fixed by aliasing `@sentry/nextjs` → `compat/sentry-nextjs.ts` (re-exports `@sentry/react`, same deduped 10.59.0, plus explicit stand-ins for the three Next-only APIs) in the Vite build only. Verified: fresh build has zero Next-internals markers in any chunk; table editor loads clean; full E2E suite run against the built bundle. Note for the stack: `alaister/tanstack-start` / the E2E-matrix branch already carried a different fix for the same crash (a `next/constants` shim) that never made it to master — the cherry-pick onto those branches keeps **both** (the shim covers any other transitive importer; the alias keeps Next internals out of the client bundle entirely). **Follow-up found while fixing:** Sentry is never *initialized* in the TanStack runtime — `instrumentation-client.ts` / `sentry.server.config.ts` are Next-convention files nothing imports under TanStack, so `captureException` calls are silent no-ops. Needs an `@sentry/react` init (+ `tanstackRouterBrowserTracingIntegration`) wired into the TanStack client entry as its own PR. ## 10. GraphiQL Monaco workers + edge-function Deno typings (Vite-only gaps) - **GraphiQL's Monaco workers ran on the main thread** under Vite ("Could not create web worker(s)…" — `setup-workers/webpack`'s `new URL(...)` form isn't rewritten by Vite). A `graphiqlViteWorkers()` plugin resolves the import to graphiql's own `setup-workers/vite` variant for client builds (SSR untouched, Next untouched); the setup-workers chain is `optimizeDeps.exclude`d because the Rolldown optimizer can't load `?worker` ids. - **Edge-function editors silently lost their Deno typings** — `AIEditor` loaded `public/deno/*.d.ts` via `/* @vite-ignore */` imports that always failed at runtime under Vite. The `.md` raw loader is generalized into `rawTextLoader` (exact-path allowlist for the two typings files, served as virtual string modules so the dep scanner never parses `.d.ts` syntax), and the imports are now static-analyzable literals that both bundlers handle (turbopack's raw-loader rules match them on the Next side). ## Split out for reviewability App-level fixes that reproduce on the Next build too (DOM-nesting hydration errors, the ghost deleted-snippet nav, the recurring pg-meta `migrations` 400) moved to their own PR: #47667. Sentry initialization for the TanStack runtime (captures were silent no-ops) is #47666, stacked on this PR. ## Full-site test campaign Drove every dashboard product area on the local TanStack build (Playwright, human-style) hunting migration regressions: redirects/404/catch-alls, org, account, project home/branches/merge, table editor CRUD, SQL editor (Monaco/run/save/templates/AI), all database pages, all auth pages, storage CRUD, edge functions + realtime, logs/observability, advisors, settings, integrations hub incl. nested routes, global UI (palette/connect/switchers/theme/fonts), and a cross-cutting sweep (document titles, back/forward chain, hard-refresh hydration on deep URLs, trailing-slash active state). Every failure found is fixed above and re-verified in-browser; remaining console quirks were cross-checked against the deployed Next build and are pre-existing (tracked separately). ## To test Most fixes are already browser-verified + covered by unit tests and the self-hosted E2E suite; the last two landed after the final browser pass and still need an in-browser check: 1. **GraphiQL Monaco workers** — restart the dev server (clear `apps/studio/node_modules/.vite` once first — the optimizer cache may hold a stale prebundle of the worker chain). Open `/project/<ref>/integrations/graphiql/graphiql` with the console open: the `Could not create web worker(s). Falling back to loading web worker code in main thread` warning must be gone, and DevTools → Sources → Threads shows the three workers (json, editor, graphql). Autocomplete in the query editor stays responsive. 2. **Edge-function Deno typings** — `/project/<ref>/functions/new`: no "Failed to load … typings" console error, and typing `Deno.` in the editor offers typed completions (e.g. `Deno.env`). Spot-checks for the rest (all previously verified): - `/project/<ref>/merge` renders (no "Module path" crash). - Multi-line SQL in Logs Explorer survives Run → reload (no `desclimit` gluing, no LIMIT-lint false failure); `s` param keeps `%0A`. - `/auth/providers` → open a provider → `?provider=…` with no trailing slash before `?`; table-editor filter/sort URLs carry no leaked `ref`/`id` params; `/?next=new-project&projectName=x` lands on `/new/new-project?projectName=x`. - Integration detail pages (cron/queues/vault/data_api) show their overview prose; GraphiQL query editor mounts. - Built bundle (`MODE=test vite build` + `start:tanstack`): table editor loads with no `process is not defined`. - `curl -sI` any page on a platform deploy: `X-Content-Type-Options: nosniff` (was the invalid `no-sniff`). <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Centralized integration overview markdown loading with registry-based lookup. * Improved Monaco loading/asset path handling for smoother editor startup. * **Bug Fixes** * Next-style navigation/search handling now preserves pathname, hash, repeated query keys, and special characters (including newlines). * Redirects now reliably carry over query and hash with correct precedence. * **Security/Configuration** * Updated CSP font sourcing and unified security headers delivery across environments; conditional HSTS behavior. * Refreshed font CSS variables and font-face definitions to match the theme. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --- ### Review feedback: non-prod favicon (Joshen) The TanStack `__root.tsx` hardcoded the prod favicon; local + hosted staging now use the white staging favicon (`/favicon/staging`), matching what `pages/_app.tsx` passes to `MetaFaviconsPagesRouter` for non-prod. Rather than pull the pages-router component into the TanStack head, it reuses the same synchronous `NEXT_PUBLIC_ENVIRONMENT` signal the file already uses for `IS_DEV_TOOLBAR_ENABLED` (the `head()` route option isn't a React component, so it can't run `_app`'s async CLI check — but the env signal covers the reported local/staging case). --------- Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com> Co-authored-by: Joshen Lim <joshenlimek@gmail.com> |
||
|
|
9eab4f8fbf |
build(studio): Vite/TanStack-Start build pipeline behind flag (stack 1/6, from #46424) (#47107)
**Stack 1/6** of the TanStack Start migration (#46424), split into reviewable, independently-mergeable PRs. > [!IMPORTANT] > **Next stays the default and only active framework after this PR.** This wires up the Vite/TanStack-Start build pipeline behind the `STUDIO_FRAMEWORK` flag, but there are no TanStack routes yet — so the TanStack build isn't functional or tested until later PRs in the stack. Nothing about the Next build, dev, or deploy changes behaviourally here. ## What's in this PR - **Dispatch:** `dev`/`build`/`start` now go through `scripts/dispatch.js`, which runs the Next variant unless `STUDIO_FRAMEWORK=tanstack`. The original commands are preserved as `dev:next`/`build:next`/`start:next`. - **Build pipeline:** `vite.config.ts`, `serve.js`, `smoke-server.mjs`, vite/tanstack deps, `turbo.jsonc`. - **`tsconfig.json`:** `jsx: react-jsx`, `moduleResolution: Bundler`, `target: ES2022`. Because `include` is `**/*.ts(x)`, this re-typechecks the whole app, so the companion adaptations below land with it. - **Shared adaptations (companions to the tsconfig change):** `BufferSource` casts, `packages/ui` unused-`React` import removals, etc. - **Routing/middleware plumbing:** `next.config.ts` + `redirects.shared.ts` (redirect rules now shared with `vercel.ts`), `proxy.ts`/`start.ts` middleware + `hosted-api-allowlist.ts`. ## Verification Run locally off `master`: frozen install ✓, `studio` typecheck ✓, **Next build ✓** (compiles + generates all routes), lint ratchet ✓ ("some rules improved"), prettier ✓. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added a hosted API endpoint allowlist to return 404 for non-supported `/api/*` routes. * Introduced a TanStack route-migration checklist and expanded TanStack Start routing support. * **Improvements** * Enhanced deployment refresh/detection by tightening cookie handling for “latest deployment” updates. * Centralized redirect/maintenance-mode rules for consistent platform vs self-hosted behavior. * Improved production serving with a dedicated static + proxy server and a post-build smoke test. * **Dependencies** * Updated TanStack-related packages and React Table/query tooling versions. * **Documentation / Chores** * Updated formatting and tooling config; added shared build environment parsing utilities. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com> Co-authored-by: Ivan Vasilov <vasilov.ivan@gmail.com> |
||
|
|
c721e8fa8f |
chore(studio): rename SQL Editor sidebar items (#46241)
## What kind of change does this PR introduce? Chore. Rename / UX copy update in Studio's SQL Editor. ## What is the current behavior? The SQL Editor sidebar has a **Community** section containing two pages: - **Templates**: reusable SQL snippets for common tasks - **Quickstarts**: end-to-end examples and starter projects The section label "Community" is misleading because these are first-party presets maintained by the Supabase team, not user-contributed content. "Quickstarts" also doesn't clearly convey "end-to-end example". ## What is the new behavior? - **Community** → **Reference** (sidebar section header) - **Quickstarts** → **Examples** (route: `/sql/quickstarts` → `/sql/examples`) - Templates keeps its name and route (`/sql/templates`), description updated to "Reusable SQL snippets for common tasks" Taxonomy: - **Templates** = reusable SQL patterns you adapt - **Examples** = end-to-end walkthroughs you run as-is A permanent redirect is added so `/sql/quickstarts` gracefully forwards to `/sql/examples`. The existing `/sql/templates` route is unchanged. | Before | After | | --- | --- | | <img width="1024" height="759" alt="Quickstarts SQL Editor Pickles Pantry Supabase-644881A5-6396-43AA-9AC4-61FFFFF18831" src="https://github.com/user-attachments/assets/ff876c78-c499-4bac-b1ae-91e31817511d" /> | <img width="1024" height="759" alt="Examples SQL Editor Pickles Pantry Supabase-573775FA-E38F-4F8D-92E3-114237410C36" src="https://github.com/user-attachments/assets/bdb8910f-94e9-4c21-bb3a-f6513008d8bc" /> | ## Additional context - `CommunitySnippetsSection.tsx`: header label + route keys updated; the underlying `community` localStorage key is intentionally unchanged to avoid resetting stored collapsed/expanded state for existing users. - ESLint rule baselines and a docs troubleshooting link updated to reflect the new filenames/routes. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Updated troubleshooting guide to reference the correct SQL examples location. * **New Features** * Renamed "Quickstarts" to "Examples" throughout the SQL editor for improved clarity. * Updated SQL template and examples section descriptions and labels to better reflect their purpose. * Reorganized SQL editor navigation to streamline access to templates and examples. <!-- review_stack_entry_start --> [](https://app.coderabbit.ai/change-stack/supabase/supabase/pull/46241?utm_source=github_walkthrough&utm_medium=github&utm_campaign=change_stack) <!-- review_stack_entry_end --> <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com> Co-authored-by: Joshen Lim <joshenlimek@gmail.com> |
||
|
Joshen Lim
|
5f867e5f6c |
Feature Preview: RLS Tester (#45121)
## Context Resolves FE-3077 Related discussion: https://github.com/orgs/supabase/discussions/45233 Verifying the correctness of your RLS policies set up has always been a gap, as highlighted by a number of GitHub discussions like [here](https://github.com/orgs/supabase/discussions/12269) and [here](https://github.com/orgs/supabase/discussions/14401). As such, we're piloting a dedicated UI for RLS testing (using role impersonation as the base), in which you'll be able to - Run a SQL query as a user (not logged in / logged in - this is the role impersonation part) - See which RLS policies are being evaluated as part of the query - And hopefully be able to debug which policies are not set up correctly Changes are currently set as a feature preview - and we'll iterate as we get feedback from everyone 🙂 🙏 <img width="613" height="957" alt="image" src="https://github.com/user-attachments/assets/83c37f8a-28fc-43b3-b0ff-e28571d8710c" /> <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * RLS Tester: run queries as anon or authenticated users, view inferred SQL, per-table policy summaries, and data previews of accessible rows. * UI preview: new RLS Tester preview card and modal with opt-in toggle; RLS Tester sheet with role/user selector and query editor. * SQLEditor: “Explain” tab is always visible. * **Chores** * Added supporting API endpoints, background checks for table RLS status, and a local-storage flag to persist the preview opt-in. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Raminder SinghandJoshen Lim
|
0cb71a2497 |
feat: new marketplace db (#44574)
This PR integrates with the new marketplace db to allow Grafana (and other partners) OAuth apps to install from the integrations page. A demo of this working locally is available here: https://supabase.slack.com/archives/C01GN60J0BS/p1775551752479709. End to end flow is documented here: https://www.notion.so/supabase/Grafana-Integration-Flow-33a5004b775f80eeaf91c098beb8071f. TODO: - [ ] Make sure `NEXT_PUBLIC_MARKETPLACE_API_URL` variable is set to the new marketplace db. - [x] Test with the `marketplaceIntegrations` enabled and disabled in staging once https://github.com/supabase/platform/pull/31298 is merged and available in staging. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Add OAuth "Install integration" button that detects installed integrations and supports GET/POST install flows * Marketplace listings now include install links, installation method, partner info, and listing assets/logos * **Infrastructure** * Allow marketplace API origin for images and content in security and image config * Centralize marketplace types and switch marketplace data source for more reliable listings <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Joshen Lim <joshenlimek@gmail.com> |
||
|
Alaister YoungandAlaister Young
|
848d1a3754 |
fix(studio): use satisfies for next.config to avoid cross-version type mismatch (#44852)
Fixes the intermittent TS2345 build failure on Vercel where `nextConfig`
(typed via next@16) is not assignable to `withBundleAnalyzer`'s
parameter (typed via next@15).
**Root cause**
The monorepo has two Next.js versions — studio uses next@16 (via
catalog) while www and docs use next@15. On Vercel, pnpm sometimes
resolves `@next/bundle-analyzer`'s `next` peer types to v15 instead of
v16. The `NextConfig` type changed between versions: next@16 widens the
`headers` return type to `Header[] | Promise<Header[]>`, but next@15
expects `Promise<Header[]>` only. When the config object is annotated as
`NextConfig` (from next@16), its `headers` property gets the wider type
— which is not assignable to the narrower next@15 type expected by the
wrapper function.
**Fix**
Switch from `: NextConfig` type annotation to `satisfies NextConfig`.
With `satisfies`, TypeScript preserves the narrow inferred types from
the object literal (e.g. `async headers()` infers as `() =>
Promise<Header[]>`) while still validating the shape. These narrower
types are assignable to both next@15 and next@16 `NextConfig`, so the
build succeeds regardless of which version the wrapper functions resolve
to.
Also adds `as const` to `basePath: false` in the rewrites config, since
without the type annotation TypeScript would widen `false` to `boolean`,
which doesn't satisfy the `Rewrite` type's literal `false` requirement.
**Changed:**
- `const nextConfig: NextConfig = { ... }` → `const nextConfig = { ... }
satisfies NextConfig`
- `basePath: false` → `basePath: false as const` in rewrites
## To test
- Typecheck passes locally: `pnpm typecheck --filter=studio`
- Verify the next Vercel deploy doesn't hit the TS2345 error
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Refactor**
* Improved TypeScript type safety in build configuration with better
type narrowing and inference.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com>
|
||
|
Alaister YoungandAlaister Young
|
f8183479e7 |
chore(studio): switch to type: module and convert configs to ESM/TS (#44839)
Switch studio's package.json to `"type": "module"` so the package runs as native ESM. This aligns the runtime module system with what we actually write (`import`/`export`), improves tree-shaking, and reduces friction with ESM-only dependencies. **Changed:** - `next.config.js` → `next.config.ts` – ESM imports/exports, proper TS types, fixed type narrowing on redirect `has` and `basePath` fields - `csp.js` → `csp.ts` – `module.exports.getCSP` → named `export function` - `tailwind.config.js` → `tailwind.config.ts` – ESM imports - `postcss.config.js` – `module.exports` → `export default` (stays `.js` since PostCSS doesn't support TS configs) **Removed:** - Unused `path` import in next config - Deprecated Sentry `hideSourceMaps` option (default behavior in Sentry v10) **Added:** - Type declaration for `config/tailwind.config` CJS package ## To test - A general smoke test of studio should suffice <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Refactor** * Modernized the Studio package to ES module style and improved TypeScript typings and config declarations to reduce build/runtime issues. * Updated styling and post-processing configuration format for more consistent tooling behavior. * **Chores** * Updated code ownership entries to reflect migrated/renamed configuration files. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com> |
