import type { OpenNextConfig } from "@opennextjs/aws/types/open-next";
const config = {
  default: {
    // 这是默认服务器，类似于 open-next v2 中的 server-function
    // 你不需要提供以下内容，默认情况下它会生成输出
    // 用于像 open-next v2 中的普通 lambda
    override: {
      // 这是启用 lambda 流式传输所必需的，默认为 aws-lambda
      wrapper: "aws-lambda-streaming",
      // 转换服务器的输入和输出，默认为 aws-apigw-v2
      converter: "aws-apigw-v2",
      // 用于 fetch 缓存和 html/rsc/json 缓存，默认为 s3
      incrementalCache: "s3",
      // 用于外部重写，默认为 node
      proxyExternalRequest: "node",
      tagCache: "dynamodb", // 用于 revalidatePath 和 revalidateTag，默认为 dynamodb
      // 你可以通过这种方式覆盖任何属于 `LazyLoadedOverride` 的部分
      queue: () =>
        Promise.resolve({
          send: async (message) => {
            // 你的自定义代码写在这里
          },
        }),
    },
    // 这将在你的默认服务器函数中安装 sharp
    // 仅用于示例目的，你很可能不应该使用这个
    // 这可以用于每个服务器以安装额外的包
    install: {
      packages: ["sharp@0.33.5"],
      arch: "arm64",
    },
    minify: true, // 这将最小化输出
  },
  // 下面我们要定义想要部署在不同服务器中的函数
  // 仅当你想将服务器拆分为多个服务器时才使用此项
  functions: {
    ssr: {
      routes: [
        "app/api/isr/route",
        "app/api/sse/route",
        "app/api/revalidateTag/route", // app 目录 Api 路由
        "app/route1/page",
        "app/route2/page", // app 目录页面
        "pages/route3", // page 目录页面
      ], // 对于 app 目录，你需要包含 route|page，无需包含 layout 或 loading
      // patterns 需要是 cloudfront 兼容的格式
      // 这将用于生成输出
      patterns: ["api/*", "route1", "route2", "route3"],
      override: {
        wrapper: "aws-lambda-streaming",
      },
      // 这启用了捆绑的 next 服务器，速度更快并减小服务器大小
      // 这也是实验性的，可能并非在所有情况下都有效
      experimentalBundledNextServer: true, // 已弃用且在 next 14.2+ 中不支持
    },
    pageSsr: {
      // 对于 page 目录，routes 应该是 `pages/${route}` 形式，不带扩展名
      // 它应该匹配文件系统
      routes: ["pages/pageSsr"],
      // BUILD_ID 是一个特殊情况，它将被替换为实际的构建 id
      patterns: ["pageSsr", "_next/data/BUILD_ID/pageSsr.json"],
      override: {
        wrapper: "node",
        converter: "node",
        // 这对于生成 dockerfile 是必要的
        // 并且让实现知道它需要部署在 docker 上
        // 你也可以在这里提供一个字符串，它将用于创建 dockerfile
        generateDockerfile: true,
      },
    },
    edge: {
      runtime: "edge",
      routes: ["app/ssr/page"],
      patterns: ["ssr"],
      override: {},
    },
  },
  // 通过设置此项，它将为 middleware 创建另一个 bundle，
  // 并且 middleware 将部署在单独的服务器中。
  // 如果未设置，middleware 将捆绑在服务器内部
  // 它可以在 lambda@edge、cloudflare workers 或其他任何地方
  // 默认情况下它使用 lambda@edge
  // 这在参考 construct 实现中尚未实现。
  // 这是可选的，但如果你将应用拆分为多个服务器，则可能是必要的
  middleware: {
    external: true,
  },
  // 可选
  imageOptimization: {
    loader: "s3-lite", // 可以使用 LazyLoadedOverride 覆盖
    // 这对于捆绑正确版本的 sharp 是必要的
    // 你可以根据需要自定义此项
    // 默认情况下它将使用这些选项安装：
    install: {
      packages: ["sharp@0.32.6"],
      arch: "arm64",
      nodeVersion: "18",
      libc: "glibc",
    },
  },
  // 初始化函数是一个特殊的服务器，将在构建时运行以初始化缓存。
  // 默认情况下，它只初始化标签缓存。除了常见选项外，你可以使用以下选项：
  initializationFunction: {
    tagCache: "dynamodb-lite", // 可以使用 LazyLoadedOverride 覆盖
  },
  // 覆盖默认的 revalidate 函数
  // 默认情况下，适用于 lambda 和 SQS 事件。
  // 仅支持 node 运行时
  revalidate: {
    override: {
      wrapper: "aws-lambda", // 可以使用 LazyLoadedOverride 覆盖
      converter: "aws-apigw-v2", // 可以使用 LazyLoadedOverride 覆盖
    },
  },
  // 覆盖默认的 warmer
  // 默认情况下，仅适用于 lambda。
  // 如果你覆盖此项，你需要在 wrapper 中处理 warmer 事件
  warmer: {
    invokeFunction: "aws-lambda", // 可以使用 LazyLoadedOverride 覆盖
    override: {
      wrapper: "aws-lambda", // 可以使用 LazyLoadedOverride 覆盖
      converter: "aws-apigw-v2", // 可以使用 LazyLoadedOverride 覆盖
    },
  },
  // 如果你想覆盖默认构建命令，可以在此处进行
  // 默认情况下它使用 `npm run build`
  buildCommand: "echo 'skipping build'",
 
  dangerous: {
    // 这将禁用标签缓存
    // 你可以在 page router 上安全使用，在 app router 上它会破坏 revalidateTag 和 revalidatePath
    disableTagCache: true,
    // 这将禁用增量缓存
    // 通常不建议这样做，因为这对于 ISR 和 SSG 路由以及 fetch 缓存是必要的
    disableIncrementalCache: true,
    // 启用缓存拦截。每个请求都将经过缓存拦截器，如果在缓存中找到，
    // 它将直接返回而不经过 NextServer。并非每个功能都被缓存拦截器覆盖，并且
    // 如果未找到缓存，它应该回退到 NextServer。
    enableCacheInterception: true,
    // 用于确定哪个头或 cookie 优先的函数。
    // 默认情况下，middleware 头和 cookie 将覆盖 handler 头和 cookie。
    // 这对每个请求执行，且在 next config 头和 middleware 执行之后。
    // 这是一个非常简单的如何使用它的示例：
    headersAndCookiesPriority: (event) => {
      if (event.rawPath.startsWith("/api")) {
        return "middleware";
      }
      return "handler";
    },
  },
  // 来自 `buildCommand` 选项的构建输出目标文件夹的路径
  // (包含 `.next` 和 `.open-next` 文件夹的路径)。
  // 此路径相对于当前 process.cwd() - 可选，默认为 "."
  buildOutputPath: "build",
  // 到 Next.js 应用源代码根目录的路径。
  // 此路径相对于当前 process.cwd()。- 可选，默认为 "."
  appPath: "app",
  // 到 Next.js 应用的 package.json 文件的路径。
  // 此路径相对于当前 process.cwd()。- 可选
  packageJsonPath: "package.json",
  // 高级用法
  // 如果你在某个地方使用 edge 运行时（无论是外部 middleware 还是在 functions 中），我们会编译 2 个版本的 open-next.config.ts 文件。
  // 一个用于 node 运行时，一个用于 edge 运行时。
  // 此选项允许你指定用于 esbuild 编译 open-next.config.ts 的 edge 运行时的 externals
  // 如果你仅在 node 中使用一些自定义覆盖，这尤其有用
  edgeExternals: [],
} satisfies OpenNextConfig;
 
export default config;