Foundation sub-project: merged homepage+tool page, FR/EN i18n via URL
prefix, dark mode, SEO basics, and reassurance elements backed by
actual backend guarantees (1h auto-delete, 100MB max, no account).
Also fixes a real bug found via the fb2 API test: file-type sniffs a
real fb2 file's XML declaration as generic "xml", not "fb2" and not
undetected, so it never reached the undetectable-format fallback added
in the previous commit. Added an fb2->xml alias in normalizeFormat,
same pattern as the existing azw3->mobi one.
Verified empirically: fontkit has no default ESM export in this project's
"type": "module" setup (import fontkit from 'fontkit' throws). The working
form is import * as fontkit from 'fontkit'.
Empirically verified library choices (fonteditor-core, opentype.js, fontkit)
against real fonts before committing to the scope, and root-caused a
file-type/dfont MIME collision that would otherwise silently break uploads.
9 tasks covering mime.js, the ico/heic converter modules, a new
iconSize column on ConversionJob, app.js/worker.js wiring, and the
frontend size picker. Every code snippet (icojs encode/decode, the
heic-convert ESM import, prisma db execute/migrate status flags) was
verified against the actual installed/resolved packages rather than
guessed.
Reuses libheif's own LGPL/MIT-licensed with-alpha-512x512.heic sample
under both a .heic and .heif filename, verified to decode correctly
via heic-convert (the library the image format work will use). No
suitably-licensed HEVC/mif1-branded .heif-distinct sample exists that
is compatible with the pinned libheif-js version, and file-type detects
both extensions identically regardless of container brand, so the
duplicate content is sufficient to exercise the heif source-format
code path.
The documented shadow-database-free fallback for generating migration SQL
(--from-migrations ... --to-schema-datamodel ...) was never actually tested
and fails for the same P3014 reason `migrate dev` does, since
--from-migrations also requires --shadow-database-url internally. Verified
against the local dev DB that --from-schema-datasource (live introspection,
no shadow DB) diffed against --to-schema-datamodel (static file read) works
in both the no-op case and a real ADD COLUMN case, and documented that
instead. Also corrected the inaccurate claim that this matched Task 3's
approach (Task 3 used --from-empty) and moved the suggested SQL output path
out of the repo root into the OS temp directory.
Also brings markFailed's errorMessage/errorLog params in line with markDone's
existing ?? null guard, and adds orderBy to findExpiredJobs to match
findPendingJobs, for consistency.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
CLAUDE.md:
- Add the one-time `prisma migrate resolve --applied 0_init` baseline
step that must run before the first `migrate deploy` against any
environment (o2switch production included) whose conversion_jobs
table predates Prisma. Without it, migrate deploy tries to
CREATE TABLE against a table that already exists and fails, leaving
migration history stuck.
- Document the actual, tested result of `prisma migrate dev` against
the local dev DB: it fails with P3014 because convert_user lacks
CREATE DATABASE/DROP DATABASE privileges needed for the shadow
database. Document the verified fallback (`migrate diff
--from-migrations ... --to-schema-datamodel ...` + manual migration
folder + `migrate resolve --applied`) as the supported way to create
new migrations here.
README.md:
- Local development step 2 referenced the deleted db/schema.sql;
replaced with the real `prisma migrate deploy` invocation, which
creates conversion_jobs fresh on an empty local database. Reordered
so `npm install` runs first, since the migrate command needs
node_modules/@prisma/client.
- Deployment on o2switch: added the same one-time baseline step
(clearly marked, not to be repeated) before the first migrate
deploy on that server, and added `prisma migrate deploy` to the
"every subsequent deployment" checklist, after npm install and
before restarting the app.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
runCleanup previously had no try/catch around each expired job, so one
job's markCleaned/delete failure would abort the whole pass, leaving
later expired jobs' files undeleted for that run. Each iteration is now
wrapped in a try/catch that logs and continues; the returned count only
reflects jobs that actually completed the delete+markCleaned sequence.
markDone now guards outputPath/outputMimeType/outputSizeBytes/
conversionDurationSeconds with `?? null`, matching the guard createJob
already has on `quality` — Prisma treats `undefined` in a data object as
"leave the column alone" rather than binding NULL like the old raw SQL
did. Currently unreachable in practice since the worker always passes
real values, but keeps the repository defensive and consistent.
Added a cleanup.test.js case that monkey-patches
prisma.conversionJob.update to reject for one job's cleanedAt update,
asserting a later expired job in the same batch still gets cleaned.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
src/db.js imports @prisma/client at runtime, but it was listed under
devDependencies (likely merged with the `prisma` devDependency during
Task 1). A production install that omits dev dependencies would crash
on startup with a missing-module error. `prisma` (the CLI) stays a
devDependency.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Task 4 rewrote src/db.js and src/jobs/jobRepository.js to use Prisma
instead of the hand-rolled mariadb pool. This updates every remaining
call site (app.js, server.js, worker.js, cleanup.js) and the 5 test
files that still referenced getPool/closePool/pool.query, so the app
and full test suite compile and run against Prisma Client.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
anthony
