Files
OpenMAIC/next.config.ts
T
Itegel Borjiginandwyuc 7aef1bd49a fix: include sharp libvips in standalone tracing (#1407)
Two sharp versions resolve in the dependency tree (0.34.5 transitive ->
@img/sharp-libvips-* 1.2.4, 0.35.4 direct -> 1.3.3). sharp's native
libvips libraries are loaded via dlopen and are not statically analyzable,
so Next.js standalone output tracing omitted them; it traced the 1.2.4
libs while the runtime loaded sharp 0.35.4, which dlopens libvips 8.18.6.
The result was a boot failure on self-hosted Docker (Alpine/musl):

  ERR_DLOPEN_FAILED: Error loading shared library libvips-cpp.so.8.18.6:
  No such file or directory (needed by .../@img/sharp-linuxmusl-arm64/
  lib/sharp-linuxmusl-arm64-0.35.4.node)

This surfaced as "Agent runtime startup failed" and broke PDF/image
material extraction. The bug is platform-independent: it stems from the
standalone tracing dropping the wrong libvips version, so it affects any
self-hosted Docker deployment (arm64 or x64), not a specific architecture.

Force-include every @img/sharp-libvips-* native lib directory in
outputFileTracingIncludes so the libvips matching the loaded sharp binary
is always present in the standalone output, across platforms and versions.

Co-authored-by: wyuc <wang-yc24@mails.tsinghua.edu.cn>
2026-09-10 21:41:07 +02:00

70 lines
2.9 KiB
TypeScript

import type { NextConfig } from 'next';
const nextConfig: NextConfig = {
output: process.env.VERCEL ? undefined : 'standalone',
outputFileTracingIncludes: {
'/*': [
'lib/server/agent-runtime/import-pptx-worker.mjs',
'skills/openmaic/**',
'skills/agent-runtime/**',
// sharp's native libvips libraries are loaded via dlopen and are not
// statically analyzable, so Next.js standalone tracing omits them. Two
// sharp versions resolve in the tree (0.34.5 transitive -> libvips
// 1.2.4, 0.35.4 direct -> libvips 1.3.3); tracing picked the wrong one
// and the runtime dlopen of sharp 0.35.4 failed with
// "libvips-cpp.so.8.18.6: No such file or directory" on self-hosted
// Docker (Alpine/musl) deployments. Force-include every sharp-libvips
// native lib dir so the version matching the loaded sharp binary is
// always present, across platforms and sharp versions.
'node_modules/.pnpm/@img+sharp-libvips-*/node_modules/@img/sharp-libvips-*/lib/**',
],
},
typescript: {
tsconfigPath: process.env.NODE_ENV === 'production' ? 'tsconfig.build.json' : 'tsconfig.json',
},
transpilePackages: ['mathml2omml', 'pptxgenjs', '@openmaic/importer'],
// These agent packages do a runtime `import(specifier)` with a computed
// specifier (to lazily load node:fs/os/path without breaking browser/Vite
// builds). webpack can't statically analyze that and bundling it throws
// "Cannot find module as expression is too dynamic" at runtime on the server
// (the "Edit with AI" Pro-mode path), which broke the #619 keep-alive e2e.
// Mark them server-external so Next loads them natively and the dynamic
// import resolves as a real Node call.
serverExternalPackages: [
'@earendil-works/pi-ai',
'@earendil-works/pi-agent-core',
'@openmaic/generation',
// Optional peers of @openmaic/storage, reached through deliberately
// untraced dynamic imports. Externalizing keeps them out of the bundle,
// and the static anchor in lib/persistence/asset-byte-store.ts gets them
// traced into the standalone image -- without it, S3 mode and redirect
// egress cannot resolve their SDK in the shipped deployment.
'@aws-sdk/client-s3',
'@aws-sdk/s3-request-presigner',
],
experimental: {
proxyClientMaxBodySize: '200mb',
},
async headers() {
const extraAncestors = process.env.ALLOWED_FRAME_ANCESTORS?.trim();
const frameAncestors = extraAncestors ? `'self' ${extraAncestors}` : "'self'";
return [
{
source: '/(.*)',
headers: [
// X-Frame-Options only supports SAMEORIGIN (no allow-list),
// so we omit it when custom ancestors are configured.
...(!extraAncestors ? [{ key: 'X-Frame-Options', value: 'SAMEORIGIN' }] : []),
{
key: 'Content-Security-Policy',
value: `frame-ancestors ${frameAncestors}`,
},
],
},
];
},
};
export default nextConfig;