Simon AxelssonandClaude Opus 5
d428dd5018
Security Scan (SIAX Cloud) / security (push) Successful in 17s
CI (SIAX Cloud) / security (push) Successful in 26s
CI (SIAX Cloud) / integration (push) Successful in 30s
CI (SIAX Cloud) / quality (push) Successful in 37s
CI (SIAX Cloud) / security (pull_request) Successful in 15s
CI (SIAX Cloud) / integration (pull_request) Successful in 25s
Security Scan (SIAX Cloud) / security (pull_request) Successful in 26s
CI (SIAX Cloud) / quality (pull_request) Successful in 50s
0pt.app svarar i dag HTTP 402 DEPLOYMENT_DISABLED (Vercels betalningsspärr) och
har ingen självhostad ersättare igång. Det här gör appen faktiskt byggbar och
körbar på Coolify. Referens: sax3l/siax-io, som redan kör självhostat på flottan
— dess Dockerfile återanvänds i form i stället för att uppfinna ett eget mönster.
next.config.mjs:
* output: "standalone" — runtime-imagen kör `node server.js` i stället för att
släpa med pnpm, corepack och hela node_modules-trädet.
* images.unoptimized: true BORTTAGET. Det var v0-generatorns standardvärde, inte
ett val: next.config.mjs var orörd sedan "Initial commit from v0". Självhostat
är rätt lösning att låta Next optimera själv.
* poweredByHeader: false.
Dockerfile (fyra steg, samma form som siax-io):
* node:24-alpine -> node:22-alpine. Båda CI-workflowsen bygger på node 22;
att bygga och köra på samma major som grinden testar tar bort en version-skew.
* libc6-compat (sharp), icke-root `node`, HEALTHCHECK mot /api/health,
npm/npx strippat ur runtime-imagen (SIO-019-mönstret).
* --ignore-workspace borttaget: motiveringen i kommentaren var inaktuell sedan
P1-21 (pnpm-workspace.yaml har ett giltigt packages:-fält och
packages/schemas är en riktig medlem). Containerinstallationen blir därmed
bit för bit samma kommando som CI kör.
* --prod=false: Coolify injicerar NODE_ENV=production vid byggtid, och pnpm
hoppar då över devDependencies som next build kräver.
Sharp levereras i ett eget npm-steg, och det är inte godtyckligt:
next build spårar INTE sharp in i .next/standalone (verifierat: standalone-
utdatans node_modules innehöll bara next/, react/, react-dom/). Den uppenbara
lösningen outputFileTracingIncludes fungerar bevisligen inte — globben
"./node_modules/@img/**/*" får Turbopack att panika på pnpms katalogsymlänkar
("Is a directory (os error 21)") och bygget faller med exit 1. Reproducerat, inte
antaget. npm-steget lägger ett platt, symlänkfritt träd som runtime-steget kan
kopiera rakt av, pinnat till versionen i pnpm-lock.yaml, och faller hårt om
versionen inte går att läsa ut i stället för att tyst skeppa trasig optimering.
BEVISAT, inte påstått (fullständiga exitkoder i PR-beskrivningen):
* pnpm install --frozen-lockfile -> 0; next build med HELT TOM env -> 0
* docker build --no-cache -> 0; container startar, /api/health -> HTTP 200
* /api/ready utan DATABASE_URL -> HTTP 503 (faller stängt, som avsett)
* /api/0pt/* utan Bearer -> HTTP 401 (middleware kör självhostat)
* /_next/image -> HTTP 200 image/avif, 1 488 706 B PNG -> 51 161 B (29x)
* sharp laddar i runtime-imagen (libvips 8.18.6, musl-binärer)
* icke-root uid=1000, HEALTHCHECK "healthy", image 1,33 GB -> 423 MB
* typecheck 0, test 0 (930 passerade). lint/prettier faller identiskt på ren
main => pre-existerande, inte infört här. Ingen grind har rörts.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
62 lines
3.1 KiB
JavaScript
62 lines
3.1 KiB
JavaScript
/** @type {import('next').NextConfig} */
|
|
const nextConfig = {
|
|
// Självhostad drift i SIAX Cloud (Coolify + Traefik) — ersätter Vercel.
|
|
//
|
|
// "standalone" får `next build` att packa en fristående Node-server i
|
|
// .next/standalone (server.js + endast de spårade modulerna). Runtime-imagen
|
|
// behöver då varken pnpm, corepack eller ett fullt node_modules-träd: den kör
|
|
// `node server.js`. Det är det som gör att Dockerfilens runtime-steg kan
|
|
// sluta släpa med npm/npx och hela dev-beroendeträdet.
|
|
//
|
|
// Inställningen är ofarlig på Vercel — plattformen ignorerar den — så den kan
|
|
// landa före DNS-cutovern utan att röra den nuvarande deployen. Samma mönster
|
|
// som sax3l/siax-io, som redan körs självhostat på flottan.
|
|
output: "standalone",
|
|
|
|
// Skicka inte `X-Powered-By: Next.js`. Ingen funktionell skillnad, tar bara
|
|
// bort en gratis versionsupplysning.
|
|
poweredByHeader: false,
|
|
|
|
// OFÖRÄNDRAD. Pre-existerande skuld i den v0-genererade app/ + components/-
|
|
// koden (se package.json's "//scripts"-not och `typecheck:app`). Den
|
|
// BLOCKERANDE grinden är `pnpm run typecheck` över src/ + tests/, som inte
|
|
// rörs av den här ändringen. Att slå på flaggan är sitt eget arbete.
|
|
typescript: {
|
|
ignoreBuildErrors: true,
|
|
},
|
|
|
|
images: {
|
|
// `unoptimized: true` togs bort. Det var v0-generatorns standardvärde —
|
|
// next.config.mjs hade inte ändrats sedan "Initial commit from v0"
|
|
// (`git log -- next.config.mjs`) — alltså varken ett medvetet val eller en
|
|
// workaround för Vercels bildloader. Självhostat är rätt lösning att låta
|
|
// Next optimera själv.
|
|
//
|
|
// FÖRUTSÄTTNING, och den är inte gratis: Nexts bildoptimerare laddar
|
|
// `sharp` med en runtime-`require`, inte ett statiskt import. `next build`
|
|
// spårar därför INTE sharp in i .next/standalone — VERIFIERAT: ett bygge
|
|
// med enbart `output: "standalone"` gav ett .next/standalone/node_modules
|
|
// som bara innehöll next/, react/ och react-dom/. En container byggd så
|
|
// svarar fel på varje /_next/image-begäran trots att sharp finns i
|
|
// pnpm-lock.yaml (som optionalDependency till next@16.3.3).
|
|
//
|
|
// `outputFileTracingIncludes` är INTE lösningen här: globben
|
|
// "./node_modules/@img/**/*" får Turbopack att panika
|
|
// ("reading file ... @img/sharp-libvips-linux-x64 — Is a directory") när den
|
|
// träffar pnpms katalogsymlänkar inne i node_modules/.pnpm. Reproducerat i
|
|
// det här arbetet; bygget avslutades med exit 1.
|
|
//
|
|
// Sharp levereras i stället som ett eget, symlänkfritt npm-steg i
|
|
// Dockerfile (`FROM node:22-alpine AS sharp`), pinnat till exakt den version
|
|
// pnpm-lock.yaml redan löst ut. Se Dockerfilens kommentar.
|
|
//
|
|
// Ingen komponent renderar en fjärrbild i dag (`next/image` importeras på
|
|
// exakt ett ställe, components/fade-image.tsx; alla bilder ligger i
|
|
// public/), så ingen `remotePatterns` behövs ännu. Lägg till en sådan —
|
|
// aldrig den föråldrade `domains` — den dagen en extern bildvärd tillkommer.
|
|
formats: ["image/avif", "image/webp"],
|
|
},
|
|
}
|
|
|
|
export default nextConfig
|