🚨 ALL CI CHECKS MUST PASS
Your PR will not be reviewed or merged until every CI job is green. No exceptions.
Run these locally before you push:
npm run format:check # Formatting
npm run lint # Lint (--max-warnings=0)
npm run typecheck # TypeScript
npm test # Tests
npm run build # Build
npm run ci:app-boot # App boot (needs Postgres + Redis)
A red build is the single most common reason work stalls on this repo. If CI fails and you are stuck, say so in the PR — do not push a failing build and go quiet.
Also required: put Closes #<this issue number> in your PR description. Without it, GrantFox cannot link your PR to this issue.
What needs to be done
The application has seven migration files in src/migrations/ and not one of them can ever run. Give the project a working schema-management path: register migrations, add a DataSource for the CLI, fix the broken filenames, and make production schema changes deployable.
Why it matters
Look at the TypeORM configuration in src/app.module.ts:
TypeOrmModule.forRoot({
type: 'postgres',
host: ..., port: ..., username: ..., password: ..., database: ...,
autoLoadEntities: true,
synchronize: process.env.NODE_ENV !== 'production',
logging: process.env.DB_LOGGING === 'true',
}),There is no migrations path, no migrationsRun, and no migrationsTableName. TypeORM is never told the migrations exist. There is also no DataSource file anywhere in the repo (data-source.ts / ormconfig / typeorm.config), so the TypeORM CLI cannot run them by hand either.
Combine that with synchronize: NODE_ENV !== 'production' and the consequence is stark:
| Environment |
How does the schema get created? |
| dev / test |
synchronize auto-derives it from entities |
| production |
Nothing. synchronize is off and migrations are not registered. |
Production has no mechanism at all to create or alter the database schema. It works in dev purely because synchronize papers over it, which also means entity changes silently diverge from what the migrations describe — nobody notices, because the migrations never execute.
Two of the files are additionally unrunnable by name:
src/migrations/[timestamp]-create-notifications-table.tssrc/migrations/[timestamp]-create-user-favorites-table.ts
Those are literal [timestamp] placeholders. TypeORM orders migrations by the numeric timestamp in the filename, so even once migrations are wired up these two will not sort correctly. (The class inside the first one is CreateNotificationsTable1678901234567, so the intended timestamp exists — it just never made it into the filename.)
Technical context
src/app.module.ts — the TypeOrmModule.forRoot({...}) block to extendsrc/migrations/ — seven files, including 1706234567891-rollback-core-entities.ts (verify whether a "rollback" migration is intended as a migration at all, or should be a down() on its sibling)package.json — needs typeorm CLI scripts (migration:generate, migration:run, migration:revert).github/workflows/ci.yml — the smoke-test job sets TYPEORM_SYNCHRONIZE: 'true'; decide whether CI should instead prove the migrations produce a working schema
Acceptance criteria
Out of scope
- Changing the entity model or adding columns
- Switching ORM or database
- Deployment pipeline changes beyond documenting the migration step
Getting started
npm ci
grep -n "TypeOrmModule.forRoot" -A 12 src/app.module.ts
ls src/migrations
Expect drift. synchronize has been building the dev schema from entities for a long time while the migrations sat unused, so the two will almost certainly disagree. Reconciling them is the work — report what you find in a comment before writing the fix.
What needs to be done
The application has seven migration files in
src/migrations/and not one of them can ever run. Give the project a working schema-management path: register migrations, add a DataSource for the CLI, fix the broken filenames, and make production schema changes deployable.Why it matters
Look at the TypeORM configuration in
src/app.module.ts:There is no
migrationspath, nomigrationsRun, and nomigrationsTableName. TypeORM is never told the migrations exist. There is also no DataSource file anywhere in the repo (data-source.ts/ormconfig/typeorm.config), so the TypeORM CLI cannot run them by hand either.Combine that with
synchronize: NODE_ENV !== 'production'and the consequence is stark:synchronizeauto-derives it from entitiessynchronizeis off and migrations are not registered.Production has no mechanism at all to create or alter the database schema. It works in dev purely because
synchronizepapers over it, which also means entity changes silently diverge from what the migrations describe — nobody notices, because the migrations never execute.Two of the files are additionally unrunnable by name:
src/migrations/[timestamp]-create-notifications-table.tssrc/migrations/[timestamp]-create-user-favorites-table.tsThose are literal
[timestamp]placeholders. TypeORM orders migrations by the numeric timestamp in the filename, so even once migrations are wired up these two will not sort correctly. (The class inside the first one isCreateNotificationsTable1678901234567, so the intended timestamp exists — it just never made it into the filename.)Technical context
src/app.module.ts— theTypeOrmModule.forRoot({...})block to extendsrc/migrations/— seven files, including1706234567891-rollback-core-entities.ts(verify whether a "rollback" migration is intended as a migration at all, or should be adown()on its sibling)package.json— needstypeormCLI scripts (migration:generate,migration:run,migration:revert).github/workflows/ci.yml— the smoke-test job setsTYPEORM_SYNCHRONIZE: 'true'; decide whether CI should instead prove the migrations produce a working schemaAcceptance criteria
migration:runandmigration:revertagainst itTypeOrmModule.forRootregisters the migrations[timestamp]-*files are renamed to their real numeric timestamps, matching their class namesnpm run migration:runon an empty database produces a schema that boots the app withsynchronizedisableddown(), verified by runningmigration:revertback to emptyREADME.md: how to run migrations locally and in deploymentOut of scope
Getting started
npm ci grep -n "TypeOrmModule.forRoot" -A 12 src/app.module.ts ls src/migrationsExpect drift.
synchronizehas been building the dev schema from entities for a long time while the migrations sat unused, so the two will almost certainly disagree. Reconciling them is the work — report what you find in a comment before writing the fix.