@rebasepro/common 0.17.3 → 0.18.1

package/src/data/sort-dialect.ts

@@ -1,237 +0,0 @@
-import type { OrderBySortTuple, OrderBySpec, OrderByTuple } from "@rebasepro/types";
-import { isRelationAggregateSort, sortKeyToString } from "@rebasepro/types";
-
-/**
- * Sort-order wire codec.
- *
- * This is the ONLY module that knows about the colon-delimited wire format
- * (`"field:direction"`) used in HTTP query parameters, and about the JSON-array
- * form that carries a multi-column sort over the same parameter.
- * Everything else speaks {@link OrderByTuple} exclusively.
- *
- * Mirrors the filter architecture in `filter-dialect.ts`.
- *
- * @module
- */
-
-/**
- * Collapse the one-key and many-key spellings of a sort into the list form.
- *
- * `["a", "desc"]` and `[["a", "desc"]]` mean the same thing and normalize to
- * the same value; the two are told apart by whether the first element is
- * itself an array, which no field name ever is.
- *
- * This is also where a {@link RelationAggregateSort} object stops being an
- * object. Above this function a sort key may be either spelling; below it,
- * every key is a string — which is what `OrderByTuple`, the REST parameter, the
- * driver contract and the cursor all already were. Doing it here means the one
- * place that already collapses the two *shapes* of a sort also collapses the
- * two *spellings* of a key, rather than every consumer learning about both.
- *
- * @returns The keys in order of significance, or `undefined` for no sort. An
- *   empty list also returns `undefined` — "sort by nothing" is no sort, and
- *   letting `[]` through would have every layer below re-deciding what it meant.
- */
-export function normalizeOrderBy(orderBy?: OrderBySpec): OrderByTuple[] | undefined {
-    if (!orderBy || orderBy.length === 0) return undefined;
-    // An aggregate key is an object, so the first element being an array still
-    // tells the list form from the single-tuple one — no field name is an
-    // array, and neither is an aggregate key.
-    const list = Array.isArray(orderBy[0])
-        ? orderBy as OrderBySortTuple[]
-        : [orderBy as OrderBySortTuple];
-    if (list.length === 0) return undefined;
-    return list.map(([key, direction]) => [sortKeyToString(key), direction] as OrderByTuple);
-}
-
-/**
- * The most significant sort key, for a caller that can only express one —
- * a column header's arrow, a URL parameter, a driver that has not been taught
- * the list form.
- */
-export function primaryOrderBy(orderBy?: OrderBySpec): OrderByTuple | undefined {
-    return normalizeOrderBy(orderBy)?.[0];
-}
-
-/**
- * Collapse the driver-level `{orderBy, order}` pair into the list form.
- *
- * The driver contract spells a single-column sort as a field name plus a
- * separate direction, and a multi-column one as a list of tuples that leaves
- * `order` meaningless. Every driver reads both through here so neither
- * spelling has to be handled twice.
- *
- * An absent direction means ascending — the same thing a bare `?orderBy=name`
- * has always meant over HTTP. The Postgres driver used to read the same pair as
- * *descending* while Mongo read it as ascending, so one field name and no
- * direction described two different queries depending on which database was
- * underneath. Neither had a caller: every path in the workspace passes a
- * direction, which is why the disagreement went unnoticed rather than being
- * load-bearing.
- */
-export function normalizeDriverOrderBy(
-    orderBy?: string | OrderByTuple[],
-    order?: "asc" | "desc"
-): OrderByTuple[] | undefined {
-    if (!orderBy) return undefined;
-    if (typeof orderBy === "string") return [[orderBy, order === "desc" ? "desc" : "asc"]];
-    return orderBy.length > 0 ? orderBy : undefined;
-}
-
-/** A sort whose *shape* is unusable, as opposed to one naming a field that does not exist. */
-export class OrderBySpecError extends Error {
-    readonly code = "INVALID_ORDER_BY";
-    constructor(detail: string) {
-        super(
-            `Invalid \`orderBy\`: ${detail}. Expected a field name, or a list of ` +
-            "[field, direction] pairs like [[\"roles\",\"asc\"],[\"created_at\",\"desc\"]]"
-        );
-        this.name = "OrderBySpecError";
-    }
-}
-
-/**
- * Validate an `orderBy` that arrived from outside this process — a WebSocket
- * subscribe frame, a driver call from untyped JavaScript — and return it in the
- * list form.
- *
- * Strict on purpose, in the same way the REST `parseOrderByParam` is: the
- * failure mode for a shape nobody checks is not a crash but a *silently
- * different query*. A malformed entry read as a field name resolves to no
- * column, and under the lenient unknown-field mode the sort is then dropped and
- * the rows come back in whatever order the database pleased — sorted, as far as
- * the subscriber can tell, by whatever they asked for.
- */
-export function parseOrderBySpecStrict(raw: unknown, order?: "asc" | "desc"): OrderByTuple[] | undefined {
-    if (raw === undefined || raw === null || raw === "") return undefined;
-    // The string spelling is the driver contract's, so it takes its direction
-    // from the same companion `order` — and defaults the same way it does.
-    if (typeof raw === "string") return normalizeDriverOrderBy(raw, order);
-    if (!Array.isArray(raw) || raw.length === 0) {
-        throw new OrderBySpecError(`${typeof raw} is not a field name or a list of sort keys`);
-    }
-
-    // The single-tuple spelling, `["created_at", "desc"]` — or the same shape
-    // with an aggregate key in place of the field name.
-    if (typeof raw[0] === "string" || isRelationAggregateSort(raw[0])) return [toStrictTuple(raw, 0)];
-
-    return raw.map(toStrictTuple);
-}
-
-function toStrictTuple(raw: unknown, index: number): OrderByTuple {
-    if (!Array.isArray(raw)) {
-        throw new OrderBySpecError(`entry ${index} has no field name`);
-    }
-    // The object spelling of an aggregate key, from an untyped caller that did
-    // not go through `normalizeOrderBy`. Encoded rather than refused: it is a
-    // sort this understands, and rejecting the shape a typed caller writes
-    // would be a distinction between the two spellings that nothing else makes.
-    const key = isRelationAggregateSort(raw[0]) ? sortKeyToString(raw[0]) : raw[0];
-    if (typeof key !== "string" || key.trim() === "") {
-        throw new OrderBySpecError(`entry ${index} has no field name`);
-    }
-    const direction = raw[1];
-    if (direction !== undefined && direction !== "asc" && direction !== "desc") {
-        throw new OrderBySpecError(`entry ${index} has direction '${String(direction)}'`);
-    }
-    return [key, direction ?? "asc"];
-}
-
-/**
- * Serialize a sort to the wire.
- *
- * A single key keeps the `"field:direction"` shorthand it has always used —
- * short, readable in a URL, and what every existing client and test expects.
- * Several keys are emitted as the canonical JSON array the server already
- * accepts, because the shorthand has no separator to spare: a comma-joined
- * `"a:asc,b:desc"` parses as one field named `a` with the direction
- * `"asc,b:desc"`, which the server refuses.
- *
- * **Runtime tolerance:** if the input is already a well-formed wire string
- * (from an untyped JS caller), it is returned unchanged.
- * This is undocumented tolerance, not public API — don't rely on it.
- *
- * @param orderBy - A canonical tuple or list of tuples, or at runtime
- *   possibly a pre-serialized string (undocumented tolerance).
- * @returns The wire-format string, or `undefined` if the input is falsy.
- *
- * @remarks
- * Field names containing `:` are representable in the tuple form but
- * **not** in the single-key wire encoding — this is an inherent limitation of
- * the colon-delimited shorthand and is not resolved here.
- */
-export function serializeOrderBy(orderBy?: OrderBySpec | string): string | undefined {
-    if (!orderBy) return undefined;
-    // Runtime tolerance: pass through a pre-serialized wire string unchanged.
-    if (typeof orderBy === "string") return orderBy;
-    // `normalizeOrderBy` has already encoded any aggregate key to its string
-    // spelling, which is why the shorthand below can assume a string: neither
-    // `min(applications.created_at)` nor `count(applications)` contains a `:`.
-    const list = normalizeOrderBy(orderBy);
-    if (!list) return undefined;
-    if (list.length === 1) return `${list[0][0]}:${list[0][1]}`;
-    return JSON.stringify(list.map(([field, direction]) => ({ field,
-direction })));
-}
-
-/**
- * Deserialize a wire-format `"field:direction"` string into an {@link OrderByTuple}.
- *
- * Lenient parsing (matches existing server behaviour):
- * - Bare field name (no colon): `"name"` → `["name", "asc"]`
- * - Unknown direction: `"name:foo"` → `["name", "asc"]`
- * - Empty / falsy input: → `undefined`
- *
- * Reads the single-key shorthand only. For a value that may carry several keys,
- * use {@link deserializeOrderByList} — handed a JSON array this returns the
- * whole array as one nonsensical field name.
- *
- * @param raw - The wire-format string from an HTTP query parameter.
- * @returns The canonical tuple, or `undefined` if the input is empty/falsy.
- */
-export function deserializeOrderBy(raw?: string): OrderByTuple | undefined {
-    if (!raw) return undefined;
-    const idx = raw.indexOf(":");
-    if (idx === -1) return [raw, "asc"];
-    const field = raw.slice(0, idx);
-    const dir = raw.slice(idx + 1);
-    return [field, dir === "desc" ? "desc" : "asc"];
-}
-
-/**
- * Deserialize either wire spelling — the single-key shorthand or the JSON
- * array — into the list form.
- *
- * Lenient in the same way {@link deserializeOrderBy} is: this is the client end
- * of the codec, where the value was produced by {@link serializeOrderBy} a
- * moment earlier. The *server* end parses the same shapes strictly, in
- * `parseOrderByParam`, because there the value came from a stranger and a
- * direction it cannot read has to be refused rather than quietly turned into
- * `"asc"`.
- */
-export function deserializeOrderByList(raw?: string): OrderByTuple[] | undefined {
-    if (!raw) return undefined;
-    const trimmed = raw.trim();
-    if (trimmed.startsWith("[")) {
-        try {
-            const parsed = JSON.parse(trimmed);
-            if (Array.isArray(parsed)) {
-                const list = parsed
-                    .map((entry): OrderByTuple | undefined => {
-                        if (typeof entry === "string") return deserializeOrderBy(entry);
-                        if (entry && typeof entry === "object" && typeof entry.field === "string") {
-                            return [entry.field, entry.direction === "desc" ? "desc" : "asc"];
-                        }
-                        return undefined;
-                    })
-                    .filter((entry): entry is OrderByTuple => entry !== undefined);
-                return list.length > 0 ? list : undefined;
-            }
-        } catch {
-            // Not JSON after all — fall through to the shorthand, which is what
-            // a field name that merely begins with "[" would be.
-        }
-    }
-    const single = deserializeOrderBy(trimmed);
-    return single ? [single] : undefined;
-}

package/src/index.ts

@@ -1,11 +0,0 @@
-export * from "./util";
-export * from "./collections";
-export * from "./data/buildRebaseData";
-export * from "./data/buildRoutedRebaseData";
-export * from "./data/resolveDataSource";
-export * from "./data/query_builder";
-export * from "./data/paginate";
-export * from "./data/filter-conditions";
-export * from "./data/filter-dialect";
-export * from "./data/sort-dialect";
-export * from "./table-classification";

package/src/table-classification.ts

@@ -1,109 +0,0 @@
-/**
- * Table Classification
- *
- * Shared constants and pure functions for classifying database tables.
- * Used by both the server-side PostgresBackendDriver and the Studio RLS editor.
- */
-
-/** Possible categories a database table can belong to. */
-export type TableCategory = "rebase-internal" | "junction" | "user";
-
-/** Schemas that are always considered Rebase-internal. */
-export const REBASE_INTERNAL_SCHEMAS: readonly string[] = ["rebase", "auth"];
-
-/** Table-name prefixes that mark a table as Rebase-internal regardless of schema. */
-export const REBASE_INTERNAL_PREFIXES: readonly string[] = [
-  "_rebase_",
-  "_auth_",
-  "drizzle_",
-];
-
-/**
- * Synchronously classify a table based on naming conventions.
- *
- * @param tableName  - The unqualified name of the table.
- * @param schemaName - The schema the table belongs to (e.g. `"public"`, `"rebase"`).
- * @returns `"rebase-internal"` when the table belongs to a reserved schema or
- *          carries a reserved prefix; `"user"` otherwise.
- *
- * @remarks
- * Junction-table detection requires an async database query and is therefore
- * **not** handled by this function. Use {@link detectJunctionTables} to obtain
- * the set of junction tables, then reclassify as needed.
- */
-export function classifyTable(
-  tableName: string,
-  schemaName: string,
-): TableCategory {
-  if (
-    REBASE_INTERNAL_SCHEMAS.includes(schemaName) ||
-    REBASE_INTERNAL_PREFIXES.some((prefix) => tableName.startsWith(prefix))
-  ) {
-    return "rebase-internal";
-  }
-
-  return "user";
-}
-
-/**
- * Convenience predicate that checks whether a table is Rebase-internal.
- *
- * @param tableName  - The unqualified name of the table.
- * @param schemaName - The schema the table belongs to.
- * @returns `true` if the table is classified as `"rebase-internal"`.
- */
-export function isRebaseInternalTable(
-  tableName: string,
-  schemaName: string,
-): boolean {
-  return classifyTable(tableName, schemaName) === "rebase-internal";
-}
-
-/** SQL query that detects junction tables in the `public` schema. */
-export const JUNCTION_TABLES_SQL = `
-  SELECT t.table_name
-  FROM information_schema.tables t
-  WHERE t.table_schema = 'public'
-    AND t.table_type = 'BASE TABLE'
-    AND NOT EXISTS (
-      SELECT 1
-      FROM information_schema.columns c
-      WHERE c.table_schema = t.table_schema
-        AND c.table_name = t.table_name
-        AND c.column_name NOT IN (
-          SELECT kcu.column_name
-          FROM information_schema.key_column_usage kcu
-          JOIN information_schema.table_constraints tc
-            ON tc.constraint_name = kcu.constraint_name
-            AND tc.table_schema = kcu.table_schema
-          WHERE tc.constraint_type = 'FOREIGN KEY'
-            AND kcu.table_schema = t.table_schema
-            AND kcu.table_name = t.table_name
-        )
-    )
-`;
-
-/**
- * Asynchronously detect junction (link) tables in the `public` schema.
- *
- * A junction table is defined as a table where **every** column participates in
- * at least one foreign-key constraint.
- *
- * @param executeSql - A callback that executes a raw SQL string and returns the
- *                     resulting rows.
- * @returns A `Set` containing the names of all detected junction tables.
- */
-export async function detectJunctionTables(
-  executeSql: (sql: string) => Promise<Record<string, unknown>[]>,
-): Promise<Set<string>> {
-  const rows = await executeSql(JUNCTION_TABLES_SQL);
-  const junctionTables = new Set<string>();
-
-  for (const row of rows) {
-    if (typeof row.table_name === "string") {
-      junctionTables.add(row.table_name);
-    }
-  }
-
-  return junctionTables;
-}

package/src/types/json-logic-js.d.ts

@@ -1,8 +0,0 @@
-declare module "json-logic-js" {
-    interface JsonLogic {
-        apply(logic: unknown, data?: unknown): unknown;
-        add_operation<T extends unknown[]>(name: string, fn: (...args: T) => unknown): void;
-    }
-    const jsonLogic: JsonLogic;
-    export default jsonLogic;
-}

package/src/util/auth-default-policies.ts

@@ -1,215 +0,0 @@
-import { CollectionConfig, SecurityRule, SecurityOperation, AuthCollectionConfig, PolicyExpression, isPostgresCollectionConfig, policy } from "@rebasepro/types";
-import { getTableName } from "./relations";
-import { getPolicyNamesForRules } from "@rebasepro/utils";
-
-/**
- * Default RLS policies injected by the schema generator.
- *
- * Rebase's enforcement model is unified: authenticated (user-context) requests
- * run under the restricted `rebase_user` role, so Postgres RLS binds *every*
- * statement — reads and writes. A collection's `securityRules` are the whole
- * authorization model. The server context (auth flows, migrations, raw
- * `rebase.sql`) runs as the owner and bypasses RLS.
- *
- * `rebase.dataAsAdmin` is **not** in that set, despite the name: it is scoped as
- * `{ uid: "service", roles: ["admin"] }`, so it runs as `rebase_user` like any
- * other caller and clears the baseline below through the *admin* arm, not the
- * server arm. Which is why `disableDefaultPolicies` plus a lone
- * `policy.serverContext()` rule locks it out too.
- *
- * Because RLS default-denies, every collection is **locked by default**: with
- * no rules, only the server context and admins can touch it. The generator
- * injects that safe baseline:
- *
- * **For every collection**
- *  1. A permissive **server-or-admin SELECT** grant.
- *  2. A permissive **server-or-admin write** grant (insert/update/delete).
- *
- * Author `securityRules` are permissive and OR together, so explicit rules only
- * *broaden* access from this locked baseline (e.g. "users read/write their own
- * rows").
- *
- * **For auth collections additionally**
- *  3. A permissive **self SELECT** grant (`id = rebase.uid()`), so users can read
- *     their own row (profile, session bootstrap) without every app re-declaring
- *     it.
- *  4. A **restrictive** admin write gate. Restrictive policies are AND'd with
- *     every other policy, so a write is rejected unless the caller is an admin
- *     (or the server context) — even if the author also wrote a permissive rule
- *     such as "a user may edit their own row". Without this, a permissive owner
- *     rule would let a user change their own `roles`.
- *
- * The server context is recognised as `rebase.uid() IS NULL` (`policy.serverContext()`)
- * — the built-in flows that run without a user (signup, migrations) set no user
- * GUC — which also lets the owner connection satisfy these policies even under
- * FORCE RLS. A *user* request never reaches that state: an anonymous one carries
- * `ANONYMOUS_USER_ID`, precisely so it cannot pass for the server here.
- *
- * Opt out with `disableDefaultPolicies: true` to take full responsibility for
- * the collection's RLS.
- */
-// Expressed structurally (not as raw SQL) so the admin UI can evaluate it
-// exactly — the framework's most security-critical policies must be reflected
-// precisely, not left as un-evaluable raw clauses. Compiles to
-// `rebase.uid() IS NULL OR (string_to_array(rebase.roles(), ',') && ARRAY['admin'])`.
-//
-// `serverContext()`, emphatically not `not(authenticated())`: the server arm of
-// this grant must match the server context and nothing else. Anonymous visitors
-// are not signed in either, so a negated `authenticated()` would hand them the
-// server-or-admin grant on every collection's default policy.
-const SERVER_OR_ADMIN_EXPR: PolicyExpression = policy.or(
-    policy.serverContext(),
-    policy.rolesOverlap(["admin"])
-);
-
-/** Write operations that must be admin-gated by default on auth collections. */
-const DEFAULT_GUARDED_OPS: SecurityOperation[] = ["insert", "update", "delete"];
-
-/** Whether a collection is flagged as an authentication collection. */
-function isAuthCollection(collection: CollectionConfig): boolean {
-    const auth = collection.auth;
-    return auth === true || (typeof auth === "object" && (auth as AuthCollectionConfig)?.enabled === true);
-}
-
-/** The property marked as the row id (falls back to `id`). */
-function getIdPropertyName(collection: CollectionConfig): string {
-    for (const [name, prop] of Object.entries(collection.properties ?? {})) {
-        if (prop && typeof prop === "object" && "isId" in prop && (prop as { isId?: unknown }).isId) {
-            return name;
-        }
-    }
-    return "id";
-}
-
-/**
- * Returns the security rules that should be applied to a collection: the
- * author's explicit `securityRules` plus the framework defaults described in
- * the module doc (baseline server/admin read for all collections; self-read
- * and the admin write gate for auth collections).
- *
- * Collections that opt out via `disableDefaultPolicies` are returned unchanged.
- */
-/**
- * The restrictive write gate for an auth collection.
- *
- * Restrictive, so it is ANDed with everything else: whatever an author's
- * permissive rules allow, a write to this table still has to satisfy this too.
- * It is the only thing standing between "users may edit their own row" and
- * "users may grant themselves any role".
- */
-function adminWriteGate(tableName: string): SecurityRule {
-    return {
-        name: `${tableName}_require_admin_write`,
-        mode: "restrictive",
-        operations: [...DEFAULT_GUARDED_OPS],
-        condition: SERVER_OR_ADMIN_EXPR,
-        check: SERVER_OR_ADMIN_EXPR
-    };
-}
-
-export function getEffectiveSecurityRules(collection: CollectionConfig): SecurityRule[] {
-    const explicit = [...(collection.securityRules ?? [])];
-
-    const tableName = getTableName(collection);
-    const injected: SecurityRule[] = [];
-
-    if (isPostgresCollectionConfig(collection) && collection.disableDefaultPolicies) {
-        // The opt-out drops the *permissive* defaults — the ones that grant.
-        // The restrictive admin-write gate on an auth collection is not among
-        // them, because it is different in kind: a restrictive policy is ANDed
-        // with every other policy and can only ever remove access, so opting
-        // out of it cannot express anything except "let more people write".
-        //
-        // Dropping it did exactly that. `{ disableDefaultPolicies: true,
-        // securityRules: [{ operation: "all", ownerField: "id" }] }` — an
-        // ordinary "users may edit their own row" configuration — let any
-        // signed-in user set their own `roles` to `["admin"]`, with no warning
-        // from any boot guard, doctor check or validator.
-        //
-        // An author who needs a different gate can add their own restrictive
-        // rule; they cannot end up with none by accident.
-        return isAuthCollection(collection)
-            ? [...explicit, adminWriteGate(tableName)]
-            : explicit;
-    }
-
-    // Baseline read + write: the server context and admins can always operate.
-    // RLS default-denies under the user role, so without these a rule-less
-    // collection would be locked to everyone — including the admin studio.
-    // Author rules are permissive and broaden access from here.
-    injected.push({
-        name: `${tableName}_default_admin_read`,
-        operations: ["select"],
-        condition: SERVER_OR_ADMIN_EXPR
-    });
-    injected.push({
-        name: `${tableName}_default_admin_write`,
-        operations: [...DEFAULT_GUARDED_OPS],
-        condition: SERVER_OR_ADMIN_EXPR,
-        check: SERVER_OR_ADMIN_EXPR
-    });
-
-    if (isAuthCollection(collection)) {
-        // Self-read: a user can always read their own row.
-        injected.push({
-            name: `${tableName}_default_self_read`,
-            operations: ["select"],
-            condition: policy.compare(policy.field(getIdPropertyName(collection)), "eq", policy.authUid())
-        });
-
-        // Restrictive gate: AND'd with all other policies, so no permissive rule
-        // (e.g. an owner "edit your own row" rule) can let a non-admin change
-        // privileged columns like `roles`. Survives `disableDefaultPolicies` —
-        // see the note above the opt-out.
-        injected.push(adminWriteGate(tableName));
-    }
-
-    return [...explicit, ...injected];
-}
-
-/**
- * The framework defaults that {@link getEffectiveSecurityRules} would add to a
- * collection, without the author's own rules.
- *
- * These policies appear in the database under names the author never wrote, and
- * a permissive policy ORs with every other permissive policy — so someone
- * reading their `securityRules` and then the real ACL sees more access than they
- * declared. Dropping them by hand does nothing either: `db push` is declarative,
- * so the next push asserts them again. Callers use this to say, in the generated
- * DDL, which policies are injected and how to take them off.
- */
-export function getInjectedSecurityRules(collection: CollectionConfig): SecurityRule[] {
-    if (isPostgresCollectionConfig(collection) && collection.disableDefaultPolicies) {
-        // Not empty for an auth collection: the restrictive write gate is still
-        // injected, and the generated DDL has to say so — a policy in the
-        // database that the author never wrote and cannot find in this list is
-        // exactly the surprise this function exists to prevent.
-        return isAuthCollection(collection) ? [adminWriteGate(getTableName(collection))] : [];
-    }
-
-    const explicitCount = (collection.securityRules ?? []).length;
-    // getEffectiveSecurityRules appends the defaults after the author's rules,
-    // so everything past the author's count is injected.
-    return getEffectiveSecurityRules(collection).slice(explicitCount);
-}
-
-/**
- * Every policy name `rebase db push` would write for a collection.
- *
- * This is the answer to "did the codebase produce this live policy?", and it is
- * more than `securityRules.map(r => r.name)` for two reasons:
- *
- *  - a rule without an explicit `name` compiles to `<table>_<op>_<hash>`, one
- *    per operation, so comparing `rule.name` to `policyname` never matches it;
- *  - the generator also injects the safe-by-default baseline
- *    (`<table>_default_admin_*`), which is in no collection's `securityRules`.
- *
- * Every UI that flags drift has to get both right, and each one that derived it
- * by hand got a different subset — which is how four policies *Rebase itself
- * wrote* came to be badged as hand-written drift on every table in a project,
- * with a button offering to import them back into the codebase that produced
- * them. There is one derivation now, and this is it.
- */
-export function getGeneratedPolicyNames(collection: CollectionConfig): Set<string> {
-    return getPolicyNamesForRules(getEffectiveSecurityRules(collection), getTableName(collection));
-}

package/src/util/builders.ts

@@ -1,82 +0,0 @@
-import {
-    CollectionConfig,
-    FirebaseCollectionConfig,
-    FirebaseProperties,
-    InferEntityType,
-    MongoDBCollectionConfig,
-    MongoProperties,
-    PostgresCollectionConfig,
-    PostgresProperties,
-    User
-} from "@rebasepro/types";
-
-
-// ── defineCollection ─────────────────────────────────────────────────────
-// A smarter builder that uses `const` type-parameter inference (TS 5.0+)
-// to capture literal property types automatically. This gives you
-// autocomplete on `display.title`, `sort`, `propertiesOrder`, `fixedFilter`,
-// callbacks, etc. — without writing `as const` or passing manual generics.
-
-/**
- * Define a PostgreSQL-backed collection with full type inference.
- *
- * The `const P` generic captures literal property types from your
- * `properties` object, which enables autocomplete on `display.title`,
- * `sort`, `propertiesOrder`, `fixedFilter`, and entity callbacks.
- *
- * @example
- * ```ts
- * const products = defineCollection({
- *     name: "Products",
- *     slug: "products",
- *     table: "products",
- *     properties: {
- *         name: { name: "Name", type: "string", validation: { required: true } },
- *         price: { name: "Price", type: "number" },
- *     },
- *     display: { title: "name" },  // ✅ autocomplete: "name" | "price"
- *     sort: ["price", "asc"], // ✅ autocomplete on first element
- * });
- * ```
- *
- * @group Builder
- */
-export function defineCollection<
-    const P extends PostgresProperties,
-    USER extends User = User
->(
-    collection: Omit<PostgresCollectionConfig<InferEntityType<P>, USER>, "properties"> & { properties: P }
-): PostgresCollectionConfig<InferEntityType<P>, USER> & { properties: P };
-
-/**
- * Define a Firestore-backed collection with full type inference.
- * @group Builder
- */
-export function defineCollection<
-    const P extends FirebaseProperties,
-    USER extends User = User
->(
-    collection: Omit<FirebaseCollectionConfig<InferEntityType<P>, USER>, "properties"> & { properties: P }
-): FirebaseCollectionConfig<InferEntityType<P>, USER> & { properties: P };
-
-/**
- * Define a MongoDB-backed collection with full type inference.
- * @group Builder
- */
-export function defineCollection<
-    const P extends MongoProperties,
-    USER extends User = User
->(
-    collection: Omit<MongoDBCollectionConfig<InferEntityType<P>, USER>, "properties"> & { properties: P }
-): MongoDBCollectionConfig<InferEntityType<P>, USER> & { properties: P };
-
-/**
- * Implementation — delegates to the correct overload at the type level.
- * At runtime this is a plain identity function.
- */
-export function defineCollection(
-    collection: CollectionConfig
-): CollectionConfig {
-    return collection;
-}
-