Florian Wilde
3db6241e9a
next/image kommt nirgends zum Einsatz — Bilder laufen ueber den eigenen Cache-Endpunkt. Damit entfaellt auch das sicherheitsrelevant aussehende dangerouslyAllowSVG, das ohnehin wirkungslos war.
33 lines
1.1 KiB
TypeScript
33 lines
1.1 KiB
TypeScript
import type { NextConfig } from "next";
|
|
|
|
const nextConfig: NextConfig = {
|
|
// Schlankes Docker-Image: Next kopiert nur die wirklich benötigten Dateien.
|
|
output: "standalone",
|
|
reactStrictMode: true,
|
|
experimental: {
|
|
// Begrenzte Zahl an Build-Workern. Mit der Voreinstellung (ein Worker je
|
|
// Kern) stürzte der Build auf einer 18-Kern-Maschine beim Einsammeln der
|
|
// Seitendaten reproduzierbar ab (Windows-Fehler 0xC0000409); jeder Worker
|
|
// zieht eine eigene Prisma-Engine hoch. Vier Worker sind schnell genug und
|
|
// laufen zuverlässig.
|
|
cpus: 4,
|
|
},
|
|
poweredByHeader: false,
|
|
serverExternalPackages: ["@prisma/client", "bcryptjs", "nodemailer"],
|
|
// Bilder laufen über den eigenen Cache-Endpunkt (/api/image), nicht über
|
|
// next/image — deshalb ist hier nichts zu konfigurieren.
|
|
async headers() {
|
|
return [
|
|
{
|
|
source: "/sw.js",
|
|
headers: [
|
|
{ key: "Cache-Control", value: "no-cache, no-store, must-revalidate" },
|
|
{ key: "Service-Worker-Allowed", value: "/" },
|
|
],
|
|
},
|
|
];
|
|
},
|
|
};
|
|
|
|
export default nextConfig;
|