From 55385adad547788539ec6f2ca8f7c99603fd1d6b Mon Sep 17 00:00:00 2001 From: Anthony Lio Date: Tue, 1 Sep 2026 17:15:55 +0300 Subject: [PATCH] fix(docs): fix tab bar overlapping code blocks (#49775) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit ## What kind of change does this PR introduce? bug fix: removes `<$CodeTabs>` from [declarative-database-schemas.mdx](https://github.com/supabase/supabase/blob/master/apps/docs/content/guides/local-development/declarative-database-schemas.mdx) following up with #49263 ## What is the current behavior? on [/declarative-database-schemas](https://supabase.com/docs/guides/local-development/declarative-database-schemas#declaring-your-schema) the tab bar above each step code block overlaps the code below it every step wraps code in `<$CodeTabs>` but carries a `-mb-6` expecting the code default margin to absorb it, while `StepHikeCompact` zeroes™ it note: it's the only page nesting `<$CodeTabs>` inside a step ## What is the new behavior? | state | preview | | -------|------| | before | image | | after | image | ## Additional context could go the other way and add `<$CodeTabs>` to those two guides for consistency but that would need StepHikeCompact to take another ! utility to restore it, but not against it if feels better. --- .../declarative-database-schemas.mdx | 56 ------------------- 1 file changed, 56 deletions(-) diff --git a/apps/docs/content/guides/local-development/declarative-database-schemas.mdx b/apps/docs/content/guides/local-development/declarative-database-schemas.mdx index 513d129fd51..404648f57b0 100644 --- a/apps/docs/content/guides/local-development/declarative-database-schemas.mdx +++ b/apps/docs/content/guides/local-development/declarative-database-schemas.mdx @@ -28,8 +28,6 @@ Schema migrations are SQL statements written in Data Definition Language. They a -<$CodeTabs> - ```sql name=supabase/schemas/employees.sql create table "employees" ( "id" integer not null, @@ -37,8 +35,6 @@ create table "employees" ( ); ``` - - @@ -53,14 +49,10 @@ create table "employees" ( -<$CodeTabs> - ```bash name=Terminal supabase db diff -f create_employees_table ``` - - @@ -75,15 +67,11 @@ supabase db diff -f create_employees_table -<$CodeTabs> - ```bash name=Terminal supabase start supabase migration up ``` - - @@ -106,8 +94,6 @@ With declarative schemas, the files in `supabase/schemas/` are the source of tru -<$CodeTabs> - ```sql name=supabase/schemas/employees.sql create table "employees" ( "id" integer not null, @@ -116,8 +102,6 @@ create table "employees" ( ); ``` - - @@ -138,14 +122,10 @@ Some entities like views and enums expect columns to be declared in a specific o -<$CodeTabs> - ```bash name=Terminal supabase db diff -f add_age ``` - - @@ -160,14 +140,10 @@ supabase db diff -f add_age -<$CodeTabs> - ```sql name=supabase/migrations/_add_age.sql alter table "public"."employees" add column "age" smallint not null; ``` - - @@ -181,14 +157,10 @@ alter table "public"."employees" add column "age" smallint not null; -<$CodeTabs> - ```bash name=Terminal supabase migration up ``` - - @@ -205,14 +177,10 @@ supabase migration up -<$CodeTabs> - ```bash name=Terminal supabase login ``` - - @@ -224,14 +192,10 @@ supabase login -<$CodeTabs> - ```bash name=Terminal supabase link ``` - - @@ -243,14 +207,10 @@ supabase link -<$CodeTabs> - ```bash name=Terminal supabase db push ``` - - @@ -260,8 +220,6 @@ supabase db push As your database schema evolves, you will probably start using more advanced entities like views and functions. These entities are notoriously verbose to manage using plain migrations because the entire body must be recreated whenever there is a change. Using declarative schema, you can now edit them in-place so it’s much easier to review. -<$CodeTabs> - ```sql name=supabase/schemas/employees.sql create table "employees" ( "id" integer not null, @@ -281,8 +239,6 @@ AS $$ $$; ``` - - Your schema files are run in lexicographic order by default. The order is important when you have foreign keys between multiple tables as the parent table must be created first. For example, your `supabase` directory may end up with the following structure. ```bash @@ -299,8 +255,6 @@ Your schema files are run in lexicographic order by default. The order is import For small projects with only a few tables, the default schema order may be sufficient. However, as your project grows, you might need more control over the order in which schemas are applied. To specify a custom order for applying the schemas, you can declare them explicitly in `config.toml`. Any glob patterns will evaluated, deduplicated, and sorted in lexicographic order. For example, the following pattern ensures `employees.sql` is always executed first. -<$CodeTabs> - ```toml name=supabase/config.toml [db.migrations] schema_paths = [ @@ -309,34 +263,24 @@ schema_paths = [ ] ``` - - ### Pulling in your production schema To set up declarative schemas on a existing project, you can pull in your production schema by running: -<$CodeTabs> - ```bash name=Terminal supabase db dump > supabase/schemas/prod.sql ``` - - From there, you can start breaking down your schema into smaller files and generate migrations. You can do this all at once, or incrementally as you make changes to your schema. ### Rolling back a schema change During development, you may want to rollback a migration to keep your new schema changes in a single migration file. This can be done by resetting your local database to a previous version. -<$CodeTabs> - ```bash name=Terminal supabase db reset --version 20241005112233 ``` - - After a reset, you can [edit the schema](#updating-your-schema) and regenerate a new migration file. Note that you should not reset a version that's already deployed to production. If you need to rollback a migration that's already deployed, you should first revert changes to the schema files. Then you can generate a new migration file containing the down migration. This ensures your production migrations are always rolling forward.