chore(jobs): change DEFAULT_MODEL_NAME to camelCase 'backgroundJob' in next major release

[lisa-assistant]

Background

In `packages/jobs/src/consts.ts` at line 18-19:

```ts
// TODO: Change this to 'backgroundJob' in the next major release
export const DEFAULT_MODEL_NAME = 'BackgroundJob'
```

Currently `DEFAULT_MODEL_NAME` is `'BackgroundJob'` (PascalCase — the Prisma schema model name). The `PrismaAdapter` then calls `camelCase()` internally to derive the actual db accessor (`db.backgroundJob`). This is confusing because the user-facing `model` option and the internal default use a different casing convention than the actual accessor.

Related TODOs in `packages/jobs/src/adapters/PrismaAdapter/PrismaAdapter.ts`:

• Line 179: `// TODO: Remove type casting of `options.model` in the next major release`
• Line 185: `// TODO: Remove the camelCase call in the next major release. It's only here to keep the code backwards compatible`

What needs to be done

In the next major release:

1. `packages/jobs/src/consts.ts` — Change the default to camelCase:
   ```ts
   export const DEFAULT_MODEL_NAME = 'backgroundJob'
   ```

2. `packages/jobs/src/adapters/PrismaAdapter/PrismaAdapter.ts` — Remove the internal `camelCase()` conversion and backwards-compat type cast. Users should now pass the camelCase model name directly (matching the Prisma client accessor). Update the JSDoc comment on the `model` option accordingly.

3. `packages/jobs/src/adapters/PrismaAdapter/tests/PrismaAdapter.test.ts` — Update the test that asserts `adapter.model === DEFAULT_MODEL_NAME`.

4. `packages/cli/src/commands/setup/jobs/jobsHandler.js` — The schema template still uses `model BackgroundJob` (PascalCase) — this stays correct for the Prisma schema, but the docs/handler should clarify that users pass `'backgroundJob'` (camelCase) to the adapter.

Why

Using PascalCase as the default for the adapter `model` option is inconsistent with how Prisma client exposes models (`db.backgroundJob`). Switching to camelCase as the canonical input makes the API more intuitive and removes the implicit `camelCase()` conversion that can mask typos in custom model names.

Migration note

This is a breaking change — users who rely on the default and don't set `model` explicitly will see no change in behavior. Users who pass `model: 'BackgroundJob'` explicitly will need to change to `model: 'backgroundJob'`. Add a migration guide entry for this.

[lisa-assistant]

Self-fix confidence: 8/10
The rename itself is straightforward. The main risk is correctly auditing all the downstream places that call camelCase() on the model name and removing them without breaking custom model name support. The existing tests provide a good safety net.

[lisa-assistant]

Implementation Plan

Goal: Change DEFAULT_MODEL_NAME from 'BackgroundJob' (PascalCase, the Prisma schema model name) to 'backgroundJob' (camelCase, the actual db accessor key), and remove the now-unnecessary camelCase() conversion and backward-compat type cast in PrismaAdapter.

---

Files to change

1. packages/jobs/src/consts.ts — line 19

// Before
export const DEFAULT_MODEL_NAME = 'BackgroundJob'

// After
export const DEFAULT_MODEL_NAME = 'backgroundJob'

2. packages/jobs/src/adapters/PrismaAdapter/PrismaAdapter.ts

Remove the | string backward-compat type from the model option (line ~130):

// Before
model?: DelegateKey<TDb> | string

// After
model?: DelegateKey<TDb>

Remove the type cast and camelCase call in the constructor (lines ~179–188):

// Before
// TODO: Remove type casting of `options.model` in the next major release
this.model = (options.model || DEFAULT_MODEL_NAME) as
  | DelegateKey<TDb>
  | string

// TODO: Remove the camelCase call in the next major release. It's only here
// to keep the code backwards compatible
const camelName = camelCase(String(this.model))
this.accessor = getDelegate(this.db, camelName)

// After
this.model = options.model ?? DEFAULT_MODEL_NAME
this.accessor = getDelegate(this.db, String(this.model))

Update the JSDoc on the model option to remove the backwards-compat note and update the @default tag:

/**
 * The camelCase name of the Prisma model accessor that represents the job
 * table, i.e. the key you'd use on `db` to query it.
 *
 * For a Prisma schema model named `BackgroundJob` this would be
 * `'backgroundJob'` (which is also the default). For a custom model named
 * `Job` this would be `'job'`.
 *
 * @default 'backgroundJob'
 */
model?: DelegateKey<TDb>

Remove the now-unused camelCase import (line 1):

// Delete this line:
import { camelCase } from 'change-case'

Check whether change-case is used anywhere else in PrismaAdapter.ts before removing — as of the current code it is not.

3. packages/jobs/src/adapters/PrismaAdapter/__tests__/PrismaAdapter.test.ts — line 48

Update the assertion for the default model name:

// Before
expect(adapter.model).toEqual(DEFAULT_MODEL_NAME)

// After — same line, but DEFAULT_MODEL_NAME is now 'backgroundJob'
expect(adapter.model).toEqual(DEFAULT_MODEL_NAME)

The test itself doesn't change — it compares against the exported constant, which is what we're updating. The test is fine as-is. But check the mock setup in beforeEach: the mockDb object should have a backgroundJob key (camelCase) for getDelegate to find. If it currently has only BackgroundJob (PascalCase), update the mock.

Look at the top of the test file to confirm the shape of mockDb — specifically whether the accessor key is already camelCase.

---

Edge cases

1. Users who explicitly pass model: 'BackgroundJob' (PascalCase): After this change, getDelegate(db, 'BackgroundJob') will try to look up db.BackgroundJob, which doesn't exist (Prisma uses camelCase accessors). This is a breaking change — appropriate for a major release. Include a migration note in the changelog: users who pass a PascalCase model name must switch to camelCase.

2. Users with custom model names: No impact if they were already passing camelCase (which the JSDoc recommends). If they were passing PascalCase custom model names (relying on the undocumented camelCase() conversion), that also breaks — same migration note applies.

3. packages/jobs/src/consts.ts is also re-exported at the package index: Verify that any downstream packages that import DEFAULT_MODEL_NAME (e.g. the CLI setup handler) use it only for comparison against the Prisma schema model name (PascalCase). The CLI's jobsHandler.js uses the string 'BackgroundJob' directly (not the constant), so it is unaffected.

4. change-case dependency: After removing the camelCase import, check whether any other file in packages/jobs imports from change-case. If not, remove it from packages/jobs/package.json.

[lisa-assistant]

Self-fix confidence: 8/10

The rename itself and the three-file cascade (consts, PrismaAdapter, test) are clear-cut. The main source of uncertainty is auditing whether any other callers pass a PascalCase model name and rely on the silent camelCase conversion — a grep is needed to be certain nothing outside packages/jobs is affected. The breaking-change nature also means a changelog entry and a migration note are required, which I can draft but which need human review before shipping.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.