add serviceRoleApiKey to kong#25
Merged
Merged
Conversation
Author
|
Also see #24 |
|
🎉 This PR is included in version 0.3.9 🎉 The release is available on: Your semantic-release bot 📦🚀 |
dumko2001
pushed a commit
to dumko2001/cli
that referenced
this pull request
Mar 15, 2026
…non-interactive setup UX (supabase#30) * fix: narrow default OAuth scopes to avoid restricted_client, add --full flag, improve non-interactive setup UX Fixes supabase#24, supabase#25 - DEFAULT_SCOPES now aliases MINIMAL_SCOPES (no pubsub/cloud-platform) which avoids Google's restricted_client 403 on unverified OAuth apps - Add FULL_SCOPES and --full flag for users who need the broader set - Replace cryptic 'run setup interactively' error with step-by-step manual OAuth console instructions including URLs, options A/B/C * chore: add changeset * chore: cargo fmt * fix: refactor format! with backslash continuations to concat! macro Address Gemini review (PR supabase#30): replace hard-to-read backslash line continuations in large format! macros with concat! for clearer structure: - manual_oauth_instructions(): full step-by-step guide - stage_configure_oauth() wizard show_message: interactive prompt text No functional change; output text is identical.
kallebysantos
pushed a commit
to kallebysantos/supabase-cli
that referenced
this pull request
May 6, 2026
## Summary This branch reshapes how the TypeScript CLI interacts with the Supabase Management API and how the generated API client is exposed to consumers. At a high level, it: - replaces the old generated `supabase platform ...` command tree with a route-first `supabase api` namespace - unifies command tracing and analytics around an explicit `CommandRuntime` - centralizes authenticated Management API access behind a shared `PlatformApi` service - simplifies `@supabase/api` to a versioned client surface rooted at `client.v1.*` - updates tests and docs to match the new command model and client contract The result is a smaller, more explicit low-level CLI surface, cleaner command instrumentation, and a more consistent API package boundary. ## Why The previous generated `platform` command tree exposed the Management API through derived CLI method names and a large amount of CLI-side metadata plumbing. That model made discovery, naming, and maintenance more complicated than necessary. This branch moves to a route-first design: - browse routes with `supabase api routes` - inspect a route with `supabase api request <route> --schema` - execute a route with `supabase api request <route> [--method ...]` That keeps the public identifier aligned with the OpenAPI route template and reduces the amount of naming logic the CLI has to own. At the same time, the branch tightens the relationship between command execution, analytics, and API requests by introducing a single per-command runtime identity that is reused for: - tracing span names - analytics context - Management API request headers ## What Changed ## CLI: New `supabase api` command model The generated `supabase platform ...` tree is removed and replaced with a smaller route-first surface: - `supabase api` - `supabase api routes` - `supabase api request <route>` Key behavior changes: - route discovery is now explicit instead of implicit through a generated command tree - method selection is route-based, with GET selected by default when a route exposes multiple methods and GET exists - schema inspection now lives on `supabase api request <route> --schema` - dry-run, field projection, multipart handling, and request prompting stay available through the new `request` flow The route-first model is backed by new command-local utilities for: - route catalog generation - route resolution - route grouping and rendering - route-specific command formatting for examples, prompts, and schema guidance ## CLI: Shared Management API service Management API access is now centralized behind a shared `PlatformApi` service and layer. This layer: - resolves the access token from CLI config or stored credentials - fails with a dedicated auth-required error when no token is available - creates the API client via `@supabase/api/effect` - injects shared request headers: - `X-Supabase-Command` - `X-Supabase-Command-Run-ID` This service is now used by: - `link` - `update` - `branches create` - `branches list` - route-first API execution and metadata-backed descriptors - project-link remote lookups ## CLI: Command runtime and instrumentation The old `withCommandAnalytics(...)` helper is replaced with `withCommandInstrumentation(...)`. This refactor introduces: - `CommandRuntime` - `commandRuntimeLayer(...)` - helper functions to derive the analytics command name and tracing span name from command path segments Each command now provides its runtime path explicitly, which is then reused for: - analytics context - tracing span names - per-command run ids - Management API request headers This removes duplicate command-name plumbing and makes command identity a first-class runtime concept instead of something reconstructed independently by analytics and API layers. ## CLI: Existing commands migrated to the new instrumentation model Command handlers across the CLI were updated to use the new runtime/instrumentation flow, including: - `init` - `login` - `logout` - `telemetry` - `branches create` - `branches list` - `link` - `unlink` - `logs` - `start` - `stop` - `status` - `stack list` - `stack update` This keeps the existing command surfaces in place while aligning them with the new command runtime and shared instrumentation model. ## API package: versioned client-only surface `@supabase/api` is simplified so that the public callable client surface is versioned under `v1`. Examples: - promise client: `client.v1.listAllProjects()` - effect client: `client.v1.listAllProjects()` Notable API package changes: - generated standalone `effect-operations` output is removed - a generated nested `effect-client` artifact is added instead - the effect and promise facades now recursively wrap nested operation namespaces - public raw client exports such as the internal service/layer-style entrypoints are no longer exposed from the main effect entrypoint This makes the package boundary clearer: - consumers use the generated contracts plus `makeApiClient` / `createApiClient` - CLI internals can still rely on the generated operation metadata and executor - public consumers no longer need to understand the old unversioned facade behavior ## API package: request header support The internal API client now accepts optional default headers in its config and applies them to every request alongside: - Authorization - User-Agent This is what enables the CLI to propagate command metadata into Management API requests without custom wrapping at every callsite. ## API package: Node entrypoint alignment The Node entrypoint now constructs its dispatcher using the `@effect/platform-node` Undici surface so that the runtime stays aligned with the dispatcher types expected by `NodeHttpClient`. This avoids cross-version type mismatches and keeps `packages/api` type-check clean. ## Metadata and schema generation updates The route-first CLI surface required changes in how the CLI consumes generated API metadata: - route grouping now comes from OpenAPI tags - descriptors track available methods for the same route - request/response schema introspection feeds route-first schema output - generated examples now render `supabase api request ...` commands - route metadata tests now validate method+route coverage instead of command-path coverage This keeps the metadata source of truth in the generated API package while reducing CLI-owned naming rules. ## Documentation updates Docs were updated to reflect the new architecture and usage patterns: - CLI README command examples and package-manager usage - analytics documentation - porting-status notes - platform-command generation documentation - `@supabase/api` README The docs now consistently describe: - the route-first `supabase api` workflow - the versioned `client.v1.*` API contract - updated local development commands using `pnpm` ## User-Facing Impact ## New low-level API UX Users now interact with the Management API through: - `supabase api routes` - `supabase api request <route>` instead of the old generated `supabase platform ...` command tree. Benefits: - route discovery is explicit - the public identifier matches the OpenAPI route template - one generic command surface supports schema inspection, dry runs, projections, and execution ## Existing command UX preserved where appropriate Higher-level commands like `link`, `branches create`, `branches list`, `start`, `stop`, and `status` keep their user-facing command names, while their internals move to the shared runtime/instrumentation and shared Management API service. ## Breaking / Compatibility Notes This branch intentionally changes internal and low-level public surfaces. Notable compatibility changes: - the old generated `supabase platform ...` command tree is removed - schema inspection through the old `platform schema ...` command is removed - the low-level API entrypoint is now `supabase api` - the public API client callable surface is versioned under `v1` - the older unversioned facade behavior is removed - the previous generated standalone effect-operation artifact is removed This is consistent with the repo’s refactoring policy: internal compatibility is not treated as a constraint when a cleaner architecture is available. ## Reviewer Notes The easiest way to review this branch is by area: 1. `apps/cli`: route-first API UX and command instrumentation 2. `apps/cli`: shared `PlatformApi` service and updated branches/link/update flows 3. `packages/api`: generated client surface simplification and versioned client contract 4. docs/tests: updated examples, metadata tests, and end-to-end validation The core design idea to keep in mind is: - the CLI low-level Management API surface is now route-first - command identity is centralized in `CommandRuntime` - Management API requests and analytics/tracing share the same command metadata - `@supabase/api` now exposes a clearer versioned client contract
Open
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What kind of change does this PR introduce?
bugfix
What is the current behavior?
Only client key is available to use
What is the new behavior?
service key is also available
Additional context
supabase/supabase#1253
Not sure if this is the right kind of fix.