Nick Szaunig
0920d33721
Jeder Video-Upload ohne System-ffmpeg im PATH — also jede lokale Entwicklungsumgebung unter Windows/macOS — endete mit 400 "Das Video konnte nicht verarbeitet werden.". Im Server-Log stand der eigentliche Grund: spawn \ROOT\node_modules\.pnpm\[email protected]\...\ffmpeg.exe ENOENT ffmpeg-static exportiert den Pfad zu seiner mitgelieferten Binary __dirname-relativ. Wird das Paket vom Bundler mitgebuendelt, zeigt sein __dirname auf einen virtuellen Bundle-Pfad ("/ROOT/...") statt auf das echte Verzeichnis in node_modules — genau dieselbe Ursache, aus der pdfkit hier schon als serverExternalPackage gefuehrt wird. ffmpeg-static daher ebenfalls in serverExternalPackages aufgenommen; der Kommentar erklaert die Ursache jetzt einmal fuer beide Pakete. Der Standalone-Build kopiert das Paket damit unveraendert nach node_modules (verifiziert).
59 lines
2.6 KiB
TypeScript
59 lines
2.6 KiB
TypeScript
import type { NextConfig } from "next";
|
|
|
|
const nextConfig: NextConfig = {
|
|
// Verhindert den "X-Powered-By: Next.js"-Response-Header — verrimt keinen
|
|
// funktionalen Vorteil, gibt Angreifern aber unnoetig Framework-Fingerprinting.
|
|
poweredByHeader: false,
|
|
|
|
// "standalone" buendelt eine minimale Node-Laufzeit inkl. Dependencies,
|
|
// wodurch das Docker-Image (siehe Dockerfile) deutlich kleiner bleibt.
|
|
output: "standalone",
|
|
|
|
// Pakete, die zur Laufzeit eigene Dateien ueber einen __dirname-relativen
|
|
// Pfad nachladen. Werden sie vom Bundler (Turbopack/Webpack) mitgebuendelt,
|
|
// zeigt ihr __dirname auf einen virtuellen Bundle-Pfad ("/ROOT/...") statt
|
|
// auf das echte Verzeichnis in node_modules — der Zugriff schlaegt dann mit
|
|
// ENOENT fehl. "serverExternalPackages" laesst Next.js sie stattdessen ganz
|
|
// normal per require() aus node_modules laden.
|
|
//
|
|
// - pdfkit: laedt seine Schriftart-Metadaten (.afm-Dateien).
|
|
// - ffmpeg-static: exportiert den Pfad zur mitgelieferten ffmpeg-Binary
|
|
// (siehe lib/video-transcode.ts). Gebuendelt lieferte es
|
|
// "\ROOT\node_modules\...\ffmpeg.exe" -> jeder Video-Upload ohne
|
|
// System-ffmpeg im PATH (also jede lokale Entwicklungsumgebung unter
|
|
// Windows/macOS) scheiterte mit "Das Video konnte nicht verarbeitet
|
|
// werden."
|
|
serverExternalPackages: ["pdfkit", "ffmpeg-static"],
|
|
|
|
// Turbopacks Dateisystem-Caches (.next/dev/cache & .next/cache/turbopack)
|
|
// kollidieren in diesem OneDrive-synchronisierten Arbeitsverzeichnis
|
|
// wiederholt mit der Cloud-Synchronisierung ("Failed to open database" /
|
|
// mmap-Timeout bei next dev, "Failed to compact database" beim
|
|
// next-build-Shutdown). Beide Caches werden daher deaktiviert.
|
|
experimental: {
|
|
turbopackFileSystemCacheForDev: false,
|
|
turbopackFileSystemCacheForBuild: false,
|
|
},
|
|
|
|
async headers() {
|
|
// Content-Security-Policy wird bewusst NICHT hier gesetzt: sie braucht
|
|
// eine pro Request neue Nonce (siehe proxy.ts), was ein statischer
|
|
// headers()-Eintrag hier nicht kann.
|
|
return [
|
|
{
|
|
source: "/(.*)",
|
|
headers: [
|
|
{ key: "X-Content-Type-Options", value: "nosniff" },
|
|
{ key: "X-Frame-Options", value: "DENY" },
|
|
{ key: "Referrer-Policy", value: "strict-origin-when-cross-origin" },
|
|
{ key: "Permissions-Policy", value: "camera=(), microphone=(), geolocation=(), payment=(self)" },
|
|
// Wirkt nur ueber HTTPS; im lokalen HTTP-Betrieb ignoriert der Browser den Header.
|
|
{ key: "Strict-Transport-Security", value: "max-age=63072000; includeSubDomains" },
|
|
],
|
|
},
|
|
];
|
|
},
|
|
};
|
|
|
|
export default nextConfig;
|