@palbase/backend 25.0.4 → 27.0.0

package/template/services/note.service.test.ts

@@ -1,45 +0,0 @@
-import { test } from "node:test";
-import assert from "node:assert/strict";
-
-import { NoteService } from "./note.service.ts";
-
-// WHY THIS TEST NEEDS NO DATABASE
-//
-// `NoteService` is handed the table it works on rather than reaching for the
-// singleton itself. That constructor is the seam: a stand-in goes in here, and
-// the logic — which rows, whose, in what order — is exercised without a
-// database. Test your own services the same way.
-//
-// When you want the whole database surface instead of one table, `fakeDatabase()`
-// from `@palbase/backend/test` is the stand-in.
-//
-// Node's ESM resolver wants the extension on a relative import inside a test
-// (`./note.service.ts`); this scaffold's `tsconfig.json` allows it.
-
-test("list asks only for the caller's notes", async () => {
-  const seen: unknown[] = [];
-  const notes = {
-    findMany: async (where: unknown) => {
-      seen.push(where);
-      return [];
-    },
-  };
-
-  await new NoteService(notes as never).list("u_1");
-
-  assert.deepEqual(seen, [{ user_id: "u_1" }]);
-});
-
-test("create writes ownership from the argument, never from the body", async () => {
-  const written: unknown[] = [];
-  const notes = {
-    insert: async (row: unknown) => {
-      written.push(row);
-      return row;
-    },
-  };
-
-  await new NoteService(notes as never).create("u_1", "hello");
-
-  assert.deepEqual(written, [{ user_id: "u_1", body: "hello" }]);
-});

package/template/services/note.service.ts

@@ -1,74 +0,0 @@
-import { Database } from "@palbase/backend";
-import type { Tables } from "@palbase/backend/env";
-
-// A SERVICE is where the logic lives. It is a plain class — no decorator, no DI
-// container, nothing to register. What makes the layer real is the two lines at
-// the bottom of this file, not the folder name.
-//
-// THE SEAM IS THE CONSTRUCTOR. The class is handed the table it works on rather
-// than reaching for the singleton itself, so a test constructs it with a
-// stand-in and never needs a database:
-//
-//   const svc = new NoteService(fakeNotesTable);
-//   assert.deepEqual(await svc.list("u_1"), []);
-//
-// The module then wires the real one ONCE, on the last line, and that instance
-// is what a controller imports. That module-level singleton is also the
-// supported way to hold a dependency ANYWHERE in this runtime: a controller,
-// hook, job or webhook is constructed with no arguments, and one that declares
-// a constructor parameter is refused at build with the class named — there is
-// no injector to fill it, so the field would simply be `undefined` in
-// production.
-//
-// `Database.tables.notes` is typed from `db/public.ts` through the generated
-// `palbase-env.d.ts`, which `palbase build` writes. Before the first build that
-// file does not exist yet and the table is unknown to the type checker; build
-// once and the whole surface below is typed with no import and no generic.
-
-/** One row of `notes`, exactly as `db/public.ts` declares it. */
-export type Note = Tables["notes"]["row"];
-
-/** The typed surface of one table: `insert`, `update`, `delete`, `findById`,
- * `findMany`. Naming it here is what keeps the seam ONE table wide — a test
- * fake implements five methods, not the whole `Database`. */
-type NotesTable = typeof Database.tables.notes;
-
-export class NoteService {
-  private readonly notes: NotesTable;
-
-  // Assigned in the BODY, never as a parameter property (`constructor(private
-  // notes: NotesTable)`). `npm test` runs Node's type-stripping test runner,
-  // which refuses parameter properties — and refuses them for the whole FILE,
-  // so one of them anywhere in a test's import graph reads like a dozen broken
-  // tests and is one keyword.
-  constructor(notes: NotesTable) {
-    this.notes = notes;
-  }
-
-  /** The caller's notes. The filter is written out even though the table's RLS
-   * policy already scopes the read to `auth.uid()`: the policy is the backstop
-   * that holds when a query forgets, not a reason to stop writing the query. */
-  list(userId: string): Promise<Note[]> {
-    return this.notes.findMany({ user_id: userId });
-  }
-
-  /** `user_id` is `notNull` with no default, so ownership is written here —
-   * it is not something the request body may carry. */
-  create(userId: string, body: string): Promise<Note> {
-    return this.notes.insert({ user_id: userId, body });
-  }
-
-  /** No `userId` argument, and that is not an oversight: another user's note is
-   * invisible to this read, so it comes back `null` exactly as a missing id
-   * does. Postgres enforces it, not this method. */
-  get(id: string): Promise<Note | null> {
-    return this.notes.findById(id);
-  }
-
-  remove(id: string): Promise<void> {
-    return this.notes.delete(id);
-  }
-}
-
-/** The wired instance. Controllers import THIS, never the class. */
-export const noteService = new NoteService(Database.tables.notes);