@guard-rail/core 0.1.1 → 0.2.1

package/scripts/postinstall.mjs

@@ -0,0 +1,48 @@
+// Plain, already-final JS — deliberately NOT part of the tsup build. A
+// postinstall script has to exist the instant npm/pnpm/yarn extracts the
+// package, with no dependency on a build step having run yet, which would
+// otherwise race tsup during this very monorepo's own installs (lifecycle
+// script ordering between "postinstall" and "prepare" isn't a guarantee
+// worth relying on).
+//
+// Runs after `npm install @guard-rail/core` in a consuming project — just
+// onboarding guidance, easy to miss otherwise among the rest of an install's
+// output.
+//
+// Deliberately silent in two cases:
+// - CI: this is guidance for a human at a keyboard, not something that
+//   belongs in build logs.
+// - Running inside this very monorepo: pnpm runs a workspace package's own
+//   lifecycle scripts too (already visible via the "prepare" build step on
+//   every `pnpm install`), which would otherwise print this on every
+//   contributor's install of this repo, not just a real consumer's. Resolved
+//   through the pnpm workspace symlink, this file's own real path sits under
+//   packages/guardrail/ — never inside a node_modules/ — which a real
+//   consumer's install always does.
+import { fileURLToPath } from "node:url";
+
+const isRealInstall = fileURLToPath(import.meta.url).includes("node_modules");
+
+if (isRealInstall && !process.env.CI) {
+  console.log(`
+Guardrail installed. Next steps:
+
+1. Set up the database (skip both if this Supabase project already has
+   Guardrail applied for another site — see "Many sites, one Supabase
+   project" in the README):
+     - Copy node_modules/@guard-rail/core/supabase/migrations/*.sql into
+       your own supabase/migrations/, then \`supabase db push\`.
+     - Add "guardrail" under Settings > API > Exposed schemas in the
+       Supabase dashboard.
+
+2. Wrap your root layout with withGuardrail and mark fields with <GRail>.
+   Full guide: https://www.npmjs.com/package/@guard-rail/core
+
+3. Once SUPABASE_URL / SUPABASE_ANON_KEY are set, seed yourself as the
+   first admin on a site (needs the service_role key, not the anon key —
+   Settings > API in the dashboard; pass it inline, don't store it):
+
+     SERVICE_KEY=... npx guardrail-seed-user \\
+       --email=you@example.com --password=... --site-id=my-site
+`);
+}

package/supabase/migrations/20260911000000_guardrail_init.sql

@@ -17,7 +17,12 @@
 -- sufficient — keep both.
 
 create schema if not exists guardrail;
-grant usage on schema guardrail to anon, authenticated;
+-- service_role bypasses RLS (a Postgres role attribute Supabase configures
+-- automatically), but that doesn't waive ordinary schema/table grants —
+-- without this, any service_role-authenticated call (guardrail-seed-user,
+-- say) fails with "permission denied for schema guardrail" despite using
+-- the right key entirely.
+grant usage on schema guardrail to anon, authenticated, service_role;
 
 /* ------------------------------------------------------------- members --- */
 
@@ -38,7 +43,7 @@ alter table guardrail.gr_members enable row level security;
 -- Anon has no legitimate reason to read team membership, so it gets no grant
 -- at all here (unlike gr_content, which anonymous visitors must be able to
 -- read to render the site).
-grant select, insert, update, delete on guardrail.gr_members to authenticated;
+grant select, insert, update, delete on guardrail.gr_members to authenticated, service_role;
 
 -- Does the current user hold one of these roles on this site? SECURITY
 -- DEFINER so the membership policies below can call it without recursing
@@ -121,8 +126,8 @@ create index gr_content_site_path_idx on guardrail.gr_content (site_id, path_key
 
 alter table guardrail.gr_content enable row level security;
 
-grant select on guardrail.gr_content to anon, authenticated;
-grant insert, update, delete on guardrail.gr_content to authenticated;
+grant select on guardrail.gr_content to anon, authenticated, service_role;
+grant insert, update, delete on guardrail.gr_content to authenticated, service_role;
 
 -- Anyone may read published content: this is what anonymous visitors render.
 create policy "content is publicly readable"
@@ -179,8 +184,8 @@ create index gr_repeater_items_order_idx
 
 alter table guardrail.gr_repeater_items enable row level security;
 
-grant select on guardrail.gr_repeater_items to anon, authenticated;
-grant insert, update, delete on guardrail.gr_repeater_items to authenticated;
+grant select on guardrail.gr_repeater_items to anon, authenticated, service_role;
+grant insert, update, delete on guardrail.gr_repeater_items to authenticated, service_role;
 
 -- Anyone may enumerate items: this is what renders the page for anonymous
 -- visitors, same reasoning as gr_content's public read policy.
@@ -289,8 +294,12 @@ grant execute on function guardrail.gr_ensure_bucket(text) to authenticated;
 
 /* ----------------------------------------------------------- bootstrap --- */
 -- A site with no members has nobody who can add members, and there is
--- deliberately no in-app way to grant yourself a role. Seed the first admin
--- here, replacing both values:
+-- deliberately no in-app way to grant yourself a role. Prefer the bundled
+-- `guardrail-seed-user` command (see the README's Bootstrapping section) —
+-- it creates the account via Supabase's own Admin API if it doesn't exist
+-- yet, rather than assuming one already does. The raw SQL below still works
+-- if you'd rather not use the service_role key it needs, replacing both
+-- values:
 --
 --   insert into guardrail.gr_members (site_id, email, user_id, role, status)
 --   select 'your-site-id', u.email, u.id, 'admin', 'active'