@specific.dev/spectest 0.39.0 → 0.41.0

package/dist/components/supabase.d.ts

@@ -50,17 +50,19 @@ export interface SupabaseOptions {
      */
     hostname?: string;
     /**
-     * Capture GoTrue's outgoing mail (magic links, OTPs, password recovery,
-     * invites — and signup confirmations with `autoconfirm: false`) with the
-     * standard `email()` component. **On by default**: the stack includes the
-     * capture server (`<name>-mail`) with GoTrue's SMTP wired at it, and tests
-     * read the mailbox through the typed helpers at `ctx.svc.<name>.mail`
-     * (`lastEmail` / `emails` / `clear`), each captured message rendering
-     * mail-client-style on the dashboard timeline.
+     * Capture GoTrue's outgoing mail (signup confirmations, magic links, OTPs,
+     * password recovery, invites) with the standard `email()` component. **On
+     * by default**: the stack includes the capture server (`<name>-mail`) with
+     * GoTrue's SMTP wired at it, and tests read the mailbox through the typed
+     * helpers at `ctx.svc.<name>.mail` (`lastEmail` / `emails` / `clear`), each
+     * captured message rendering mail-client-style on the dashboard timeline.
      *
-     * Signups stay one-step by default (`autoconfirm: true`) so the mailbox is
-     * purely additive; pass `{ autoconfirm: false }` to test real
-     * email-confirmation flows. Pass `{ service: "<key>" }` to point GoTrue at
+     * Signups complete in **one step** by default (`autoconfirm: true`), so
+     * the mailbox is purely additive and a suite that just needs accounts
+     * writes nothing extra. Pass `{ autoconfirm: false }` to run the real
+     * confirmation flow instead — the signup then issues no session until a
+     * test follows the emailed link out of the mailbox. Pass
+     * `{ service: "<key>" }` to point GoTrue at
      * an `email()` service the environment already declares — keep a single
      * mailbox per environment rather than one per component: if the app under
      * test also sends mail, share one `email()` between it and Supabase
@@ -81,24 +83,75 @@ export interface SupabaseOptions {
         serviceRole?: string[];
     };
     /**
-     * Auto-apply SQL migrations found in the project before any dependent service
-     * starts. `true` (default) applies every `*.sql` under `supabase/migrations/`
-     * (sorted, the Supabase convention), then `supabase/seed.sql` if present — a
-     * no-op when the directory is absent. Pass a string to point at a different
-     * directory (relative to the project root or absolute), or `false` to skip.
-     * An *explicitly configured* path that doesn't resolve is an error at env
-     * start (a silent no-op there surfaces much later as a confusing
-     * `relation … does not exist`).
+     * Where the project's SQL migrations live, e.g. `"supabase/migrations"`
+     * (relative to the project root, or absolute). **Nothing is applied unless
+     * you set this** — there is no assumed path, so a project whose schema
+     * arrives some other way (an app that migrates itself at boot, a dump
+     * restored in `setup`) never gets a second, surprising source of DDL.
+     *
+     * Every `*.sql` directly in the directory is applied in sorted filename
+     * order, then — the standard Supabase layout — the **`seed.sql` beside
+     * that directory**, if there is one:
+     *
+     * ```
+     * supabase/
+     *   migrations/0001_init.sql   ← applied, sorted
+     *   migrations/0002_todos.sql
+     *   seed.sql                   ← applied last
+     * ```
+     *
+     * It all runs **once the whole stack is up** — the same point `supabase db
+     * reset` applies migrations — so your SQL may use schema the services
+     * create when they boot (`storage.buckets`, the modern `auth.*` tables).
+     * PostgREST's schema cache is reloaded afterwards.
+     *
+     * A path that doesn't resolve is an error at env start; a silent no-op
+     * there surfaces much later as a confusing `relation … does not exist`.
      * Because `supabase/**` is project content, editing a migration correctly
      * forces a cold rebuild and re-apply (unlike `spectest/tests/**`).
      */
-    migrations?: boolean | string;
+    migrations?: string;
     /**
-     * Seed SQL applied after migrations. `true` (default) applies
-     * `supabase/seed.sql` if it exists; a string overrides the path; `false`
-     * skips it.
+     * Where the project's **edge functions** live, e.g.
+     * `"supabase/functions"` — one subdirectory per function, each with an
+     * entrypoint the runtime can serve (`supabase/functions/hello/index.ts`).
+     *
+     * **Nothing runs unless you set this.** Point at the directory and every
+     * function in it is served on the real Supabase edge runtime at
+     * `<url>/functions/v1/<name>` through the gateway — the same path
+     * `supabase.functions.invoke(...)` derives, so the app under test needs no
+     * override. Leave it unset and the runtime is left out of the stack
+     * entirely, along with the gateway's `/functions/v1` route.
+     *
+     * Function code is read straight from the repo — nothing is copied or
+     * bundled — so editing a function is an ordinary project edit.
+     *
+     * Pass an object instead of a path to turn JWT verification off, or to set
+     * the function secrets your code reads with `Deno.env.get(...)`.
      */
-    seed?: boolean | string;
+    functions?: string | SupabaseFunctionsOptions;
+}
+/** Tuning for `SupabaseOptions.functions`. */
+export interface SupabaseFunctionsOptions {
+    /**
+     * Directory holding one subdirectory per function, relative to the project
+     * root (or absolute). Required — there is no assumed location.
+     */
+    dir: string;
+    /**
+     * Reject a call that carries no valid JWT, exactly as hosted Supabase
+     * does. Default `true` — so a test that forgets the `Authorization`
+     * header fails here instead of in production. Set `false` for the
+     * `--no-verify-jwt` behaviour (webhooks, public endpoints).
+     */
+    verifyJwt?: boolean;
+    /**
+     * Extra environment variables the functions read (`Deno.env.get("…")`) —
+     * the local stand-in for function secrets. `SUPABASE_URL`,
+     * `SUPABASE_ANON_KEY`, `SUPABASE_SERVICE_ROLE_KEY`, `SUPABASE_DB_URL` and
+     * `JWT_SECRET` are already set for you.
+     */
+    env?: Record<string, string>;
 }
 /** Tuning for `SupabaseOptions.mail`. */
 export interface SupabaseMailOptions {
@@ -110,10 +163,17 @@ export interface SupabaseMailOptions {
      */
     service?: string;
     /**
-     * Whether GoTrue autoconfirms signups. `true` (default): signups complete
-     * in one step and send no confirmation mail — recovery, magic-link and OTP
-     * mail is still sent and captured. Set `false` to exercise real
-     * email-confirmation flows (signups require the emailed verification).
+     * Whether GoTrue confirms a signup without the emailed verification.
+     * **`true` by default**: signups complete in one step and send no
+     * confirmation mail, which keeps account creation a single call in the
+     * suites where it is setup rather than the thing under test.
+     *
+     * Set `false` to run the flow a hosted project runs: the signup issues no
+     * session, and the test follows the emailed link out of the mailbox
+     * exactly as a user would (see `examples/supabase-app`). Recovery,
+     * magic-link, OTP and invite mail is sent either way. Forced `true` when
+     * the stack has no mailbox (`mail: false`), since the confirmation would
+     * go nowhere.
      */
     autoconfirm?: boolean;
     /** Sender address GoTrue mails from. Default `admin@example.com`. */