Markitup

This is a Next.js project bootstrapped with create-next-app.

Environments

This project uses a cloud Supabase project per environment — no Docker, no Supabase CLI. Two environments:

	Env file	Supabase project	Used by
Development	.env.development.local	your own dev project	npm run dev
Production	.env.local	the live project	migration scripts, npm run build

Next.js loads .env.development.local ahead of .env.local when you run npm run dev, so the app points at dev automatically while the production values stay available to the scripts.

Both files are gitignored. Only the .example templates are committed.

First-time local setup

1. Create a dev Supabase project at supabase.com. Name it something unmistakable, e.g. markitup-dev. The free tier is fine.

2. Create your dev env file:

   cp .env.development.local.example .env.development.local
   

   Fill in NEXT_PUBLIC_SUPABASE_URL and NEXT_PUBLIC_SUPABASE_ANON_KEY (Settings → API), and a SUPABASE_ACCESS_TOKEN from account/tokens so the migration scripts can reach the database. Generate a dev-only FIGMA_TOKEN_SECRET; never reuse production's.

3. Build the schema. One command applies all migrations in order and records each one:

   npm run dev:migrate
   

   Check it any time with npm run dev:status.

   If that cannot connect, the last resort is the dashboard:

   npm run db:bootstrap    # writes supabase/bootstrap.sql
   

   Paste that file into the Supabase SQL Editor and Run it once. It creates everything and records all migrations as applied, so the runner will report the database as up to date. The file is generated, not committed — regenerate it whenever you need it.

4. Create the storage buckets. Migrations cover tables and policies, not buckets. In Supabase → Storage, create two private buckets: mockups and comment-files.

5. Turn off email confirmation. Authentication → Sign In / Providers → Email → uncheck Confirm email. With it on and no SMTP configured, a new signup produces no session and cannot enter the app.

6. Enable anonymous sign-ins (Authentication → Sign In / Providers) if you want to test public share links, which let clients comment without an account. Remember to press Save — the toggle reverts silently otherwise.

7. Run it:

   npm run dev
   

Migrations

Migrations live in supabase/migrations/ and are applied by a runner that keeps a ledger in the app_migrations schema — filename, a checksum of the contents, and when it ran.

Reaching the database

The runner takes either of two routes, and prefers the first:

• SUPABASE_ACCESS_TOKEN — an account token from account/tokens. Runs SQL over HTTPS. No database password, and it works on networks that block the Postgres port. The project comes from NEXT_PUBLIC_SUPABASE_URL, so the token is the only thing to paste. It covers your whole Supabase account, so keep it to the gitignored env file and revoke it from that page if it leaks.
• SUPABASE_DB_URL — a direct Postgres connection.

Prefer the token. A database password is shown exactly once, lives inside a URL where one wrong character changes it invisibly, and fails with 28P01 password authentication failed whether it was mistyped, never saved, or simply stale — three very different problems that look identical. If you hit that error, don't reset the password again; switch to a token.

npm run db:status      # what is applied and pending (read-only, safe on prod)
npm run db:migrate     # apply everything pending
npm run dev:status     # the same, against the dev project
npm run dev:migrate

Nothing is written unless you ask it to apply. Three rules the runner enforces:

• Order. Files run in filename order, each in its own transaction. A failure rolls that file back and stops, rather than leaving the schema half-changed.
• Exactly once. An applied migration is never re-run.
• No silent edits. If a file's contents change after it was applied, the runner refuses to apply anything until you resolve it. Fix a mistake with a new migration rather than editing an old one.

To adopt an existing database that already has every migration applied by hand, record them without executing anything:

npm run db:baseline

Writing a migration

Create supabase/migrations/00NN_short_name.sql, write the SQL with a comment explaining why, then:

npm run dev:migrate    # dev first, always
npm run test           # then the suite
npm run db:migrate     # production, once dev is proven

Google sign-in (optional)

Email/password auth works out of the box. To also enable "Sign in with Google", configure the Google provider in Supabase:

1. In the Google Cloud Console, create an OAuth 2.0 Client ID (Web application) and add https://<your-project-ref>.supabase.co/auth/v1/callback as an authorized redirect URI.
2. In the Supabase dashboard, go to Authentication → Providers → Google, enable it, and paste in the Client ID and Client Secret from step 1.
3. (If using the local Supabase CLI instead of the cloud dashboard, set the equivalent values under [auth.external.google] in supabase/config.toml.)
4. The app's OAuth callback route (app/auth/callback/route.ts) exchanges the returned code for a session and redirects to /app; no additional app code changes are required once the provider is configured.

Email notifications (Resend)

Transactional email (comment notifications, invites, welcome) is sent via Resend. Password-reset emails are sent by Supabase.

1. Create a Resend account and an API key.
2. Set these env vars (locally in .env.local, and in Vercel → Settings → Environment Variables for Production/Preview):
   • RESEND_API_KEY — your Resend API key.
   • EMAIL_FROM — sender address. Use [email protected] until you verify a domain; then set e.g. [email protected].
   • NEXT_PUBLIC_APP_URL — your live URL, e.g. https://markitup-woad.vercel.app.
3. In Supabase → Authentication → URL Configuration, add https://<your-app>/auth/callback to the Redirect URLs. The password-reset flow routes through this same route (it performs the server-side PKCE code exchange, so resets work across devices) and then forwards internally to /reset-password, which is same-origin and needs no separate allowlist entry. This is the same callback URL used by Google sign-in above, so it may already be present.
4. Go-live: verify apexure.com in Resend (add the DNS records it shows), then set [email protected]. Until then, Resend only delivers to your own verified address.

If RESEND_API_KEY is unset, the app runs normally and email sends are skipped (logged as warnings), so local dev and tests need no email config.

Running Tests

This project uses Vitest for unit tests.

npm test            # run the unit test suite once (Vitest)
npm run test:watch  # run in watch mode
npm run test:e2e    # full end-to-end core loop (Playwright, drives the real app)

Two database-backed invariants are proven by standalone scripts that run against the cloud DB (they use a transaction and roll back, leaving no data behind):

node scripts/rls-check.mjs    # tenant-isolation RLS (self-join denied, owner bootstrap allowed)
node scripts/pins-check.mjs   # per-mockup sequential pin numbering

Getting Started

First, run the development server:

npm run dev
# or
yarn dev
# or
pnpm dev
# or
bun dev

Open http://localhost:3000 with your browser to see the result.

You can start editing the page by modifying app/page.tsx. The page auto-updates as you edit the file.

This project uses next/font to automatically optimize and load Geist, a new font family for Vercel.

Learn More

To learn more about Next.js, take a look at the following resources:

• Next.js Documentation - learn about Next.js features and API.
• Learn Next.js - an interactive Next.js tutorial.

You can check out the Next.js GitHub repository - your feedback and contributions are welcome!

Deploy on Vercel

The easiest way to deploy your Next.js app is to use the Vercel Platform from the creators of Next.js.

Check out our Next.js deployment documentation for more details.