Shared configuration packages

A small cluster of packages that hold shared tooling configuration consumed by the apps and other packages.

packages/config

Shared runtime configuration — environment-derived constants used by multiple apps. Apps import via:

import { someConstant } from 'config';

packages/tsconfig

Shared TypeScript configuration. Each app and package extends one of these:

{
  "extends": "tsconfig/base.json",
  // ...
}

The configs encode the workspace-wide compiler choices (target, module, lib, strict mode, etc.) so individual packages don't drift.

packages/eslint-config-supabase

Shared ESLint configuration. Plug into a flat config:

// eslint.config.cjs
const supabase = require('eslint-config-supabase');
module.exports = [...supabase /* package-specific overrides */];

Studio extends this with its own custom rules and the lint-ratchet machinery (see Tooling).

Why three small packages?

Each one targets a distinct tool. Splitting them makes it easy to depend on one without pulling the others into a dependent package's classpath.

Entry points for modification

• Add a runtime constant → extend packages/config and re-export from its barrel.
• Tighten TypeScript options → edit packages/tsconfig/<base|nextjs|...>.json. The change reaches every consumer on next build.
• Adjust ESLint → edit packages/eslint-config-supabase. Run pnpm lint across the workspace to see the impact.

Integration points

• Every app and package extends or imports at least one of these.
• Studio is the most opinionated consumer — it adds custom rules on top of eslint-config-supabase and adds Next.js-specific options on top of tsconfig.