[Enhance Request] 镜像瘦身

[john5du]

背景

当前 ghcr.io/ding113/claude-code-hub:latest amd64 镜像压缩层约 226MB。初步分析后，主要体积来源不是基础镜像，而是 Next.js standalone 运行产物及重复复制的构建目录。

可选瘦身方案

1. 移除重复复制的 .next/server

deploy/Dockerfile 当前复制了 .next/standalone，之后又额外复制完整 .next/server。远端镜像层分析显示，.next/server 额外复制层约 45MB 压缩体积，且 .next/standalone 内已经包含部分 server 产物。

预期收益：约 45MB 压缩体积，优先级最高。

风险：需验证 Server Actions、App Router 页面、API routes 是否仍正常。

2. 清理生产运行不需要的 sourcemap / trace 文件

.next/server 中包含大量 .js.map 和 .nft.json 文件。运行时通常不需要 sourcemap，.nft.json 也主要用于 tracing、debug、build 分析。

预期收益：可能减少几十 MB，需实际 build 后验证。

风险：错误栈可读性下降；若某些运行时逻辑依赖 .nft.json，需要排查。

3. 收窄 next.config.ts 中的 tracing includes

当前 outputFileTracingIncludes 手动包含了：

"./node_modules/next/dist/**/*"

本地 node_modules/next/dist 未压缩约 168MB，可能导致 standalone 产物过大。可以改为只包含自定义 server 实际需要的 Next runtime 文件，而不是整个 next/dist。

预期收益：潜在收益较大，可能为几十 MB。

风险：需要仔细验证自定义 server.js、WebSocket、Next programmatic API 是否完整可用。

[coderabbitai]

🔗 Related PRs

#679 - 支持 zeabur 部署 [merged]
#1238 - feat(proxy): support compressed request bodies (zstd, gzip, deflate, br) (#1193) [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[github-actions]

Thank you for this detailed analysis and set of optimization proposals. I have investigated each proposal against the current codebase.

Summary of findings:

---

Proposal 1: Remove duplicate .next/server copy

Status: Partially valid, but the extra COPY is necessary.

In deploy/Dockerfile (lines 56-58):

COPY --from=build --chown=node:node /app/.next/standalone ./
# Server Actions live inside .next/server; copy it or Next.js cannot resolve action IDs.
COPY --from=build --chown=node:node /app/.next/server ./.next/server
COPY --from=build --chown=node:node /app/.next/static ./.next/static

The first COPY brings .next/standalone/.next/server/ (a traced subset), and the second overwrites it with the full .next/server/. In Docker's layered filesystem, both layers retain their bytes, so the standalone subset in the first layer is indeed wasted space.

However, the second COPY cannot simply be removed. This project has 51 files with the "use server" directive (across src/actions/, src/repository/, and src/app/). Next.js standalone output traces dependencies and may not include all Server Action bundles — the explicit comment on line 57 confirms this was added to resolve action ID resolution failures. Removing it would likely break the dashboard UI and all Server Action calls.

Actual optimization opportunity: Instead of removing the second COPY, the waste comes from the standalone output's .next/server/ subset being included in the first layer and then overwritten. A viable approach would be to exclude .next/server/ from the standalone COPY (e.g., using a multi-step COPY or a RUN rm -rf .next/server before the second COPY) so the first layer doesn't carry dead bytes. This preserves correctness while eliminating the overlap.

---

Proposal 2: Clean up sourcemaps / trace files

Status: Valid for .nft.json files, but sourcemaps are likely not generated.

next.config.ts does not set productionBrowserSourceMaps: true, so Next.js should not generate .js.map files in production builds. The .nft.json (Node File Trace) files, however, are generated by Next.js's file tracing system during next build and are included in both .next/server/ and .next/standalone/. These are build-time artifacts used for dependency tracing and are not needed at runtime.

A cleanup step in the Dockerfile (e.g., RUN find .next -name "*.nft.json" -delete) after the COPY steps could reclaim some space. The risk is minimal — these files are not read at runtime by Next.js or the custom server.

---

Proposal 3: Narrow outputFileTracingIncludes for next/dist

Status: Valid concern but requires careful validation.

In next.config.ts (lines 29-43):

outputFileTracingIncludes: {
  "/**": [
    "./node_modules/undici/**/*",
    "./node_modules/fetch-socks/**/*",
    "./node_modules/ws/**/*",
    "./node_modules/next/dist/**/*",
    "./node_modules/next/package.json",
  ],
},

The "./node_modules/next/dist/**/*" entry pulls the entire next/dist directory (~168MB uncompressed) into the standalone output. This was added because the custom server.js (line 648) uses require("next") to initialize Next.js programmatically:

// server.js:648
nextModule = require("next");

And then calls nextFactory({ dev, hostname, port }) (line 677) to create the Next.js app instance. The full next/dist is included to ensure all programmatic API internals are available.

Potential optimization approach: Rather than blanket-including all of next/dist, one could:

1. Build the image with the current config and inspect which files under next/dist are actually accessed at runtime.
2. Replace the glob with specific subdirectories (e.g., next/dist/server/**/*, next/dist/compiled/**/*).
3. Validate thoroughly that the custom server, WebSocket upgrade path, App Router, and all 51 Server Actions still resolve correctly.

This is the highest-effort optimization with the largest potential payoff, but also the highest risk of breaking runtime behavior.

---

Additional observation: scripts/copy-version-to-standalone.cjs

This build script (called from package.json build step) copies .next/static and public into .next/standalone/ for local development convenience. These files are then copied again by the Dockerfile's explicit COPY steps. In the Docker context, the script's copies of static and public within standalone are redundant since the Dockerfile copies them from the build stage independently.

---

Automated response from Claude AI