尧图网站建设 
Inngest JS 测试应用实战Next.js SDK 集成测试床与 pnpm 供应链加固【免费下载链接】inngestThe leading workflow orchestration platform. Run stateful step functions and AI workflows on serverless, servers, or the edge.项目地址: https://gitcode.com/GitHub_Trending/in/inngest本文以 Inngest 仓库中 tests/js/README.md 为核心讲解tests/js这个 Next.js 测试应用如何作为 JS SDK 的集成测试床运行如何启动开发服务器、/api/inngest端点如何注册与暴露测试函数、.npmrc中minimum-release-age如何加固供应链以及该应用如何被仓库根目录的tests.sh与 Go 测试驱动器整体调度。读完后你能独立跑起这个测试应用并理解它在整个 Inngest 服务端集成测试体系中的角色与安全策略设计。应用定位一个专为 SDK 集成测试服务的 Next.js 应用tests/js是一个由create-next-app引导的 Next.js 项目见 tests/js/README.md 开头声明其package.json中名为inngest-js-tests并声明了packageManager: pnpm10.18.2。它不是面向最终用户的产品应用而是承载 Inngest JS SDK 测试函数、供仓库内 Go 测试代码tests/目录下的sdk_*_test.go系列跨进程调用的活体测试目标。从 tests/js/package.json 的依赖声明可以看出其测试床的关键设计——同时引入两代 JS SDK{ name: inngest-js-tests, private: true, packageManager: pnpm10.18.2, scripts: { dev: next dev, build: next build, start: next start, lint: next lint }, dependencies: { inngest: 3.11.1-pr-411.4, inngest-v4: npm:inngest4.3.0, zod: ^3.25.0, next: 15.5.18, react: 18.2.0, typescript: 5.6.3, ...: ... }, pnpm: { overrides: { inngest4zod: 3.25.76, postcss: 8.5.10, protobufjs7: 7.5.8, protobufjs8: 8.2.0, serialize-error-cjs: 0.1.3 } } }inngest依赖指向一个 PR 预发布版本3.11.1-pr-411.4用于测试在研的 v3 分支行为inngest-v4通过 pnpm 的npm:别名映射到正式发布的inngest4.3.0代表下一代 SDKpnpm.overrides把两棵依赖树中的zod、postcss、protobufjs等传递依赖强制钉死到特定版本。从源码结构看这些固定值是为了让 v3 与 v4 两个 SDK 版本能在同一个应用内共存且不发生依赖冲突同时锁定已出现漏洞的传递依赖版本。配套的构建配置见 tests/js/next.config.js其中开启了experimental.appDir: truetests/js/tsconfig.json 使用严格模式strict: true并通过路径别名把/*映射到./src/*代码中的/inngest/client等导入即依赖该映射。快速启动开发服务器README 给出的标准启动方式继承自原文档npm run dev # or yarn dev # or pnpm dev由于packageManager字段与pnpm-lock.yaml的存在推荐且仓库 CI 脚本实际使用的就是pnpm。启动后访问http://localhost:3000即可看到应用。README 中提到修改app/page.tsx即可编辑页面且页面支持热更新pages/api目录整体映射到/api/*目录中的文件按 API 路由处理而非 React 页面处理。需要注意两点仓库现状当前src/app下并没有page.tsx页面文件只有 API 路由见下文核心端点一节页面编辑相关描述属于create-next-app模板的通用说明README 提到的/api/hello同样是模板遗留示例仓库中真实存在的 API 路由是src/pages/api/下的 inngest.ts 与 introspect.ts。README 还说明该项目通过next/font自动优化加载 Inter 字体这与 tests/js/package.json 中的next/font依赖相互印证。核心端点serve 处理器与 introspect 探测/api/inngest函数注册与执行入口tests/js/src/pages/api/inngest.ts 是整个测试床的心脏import { serve } from inngest/next; import { inngest } from /inngest/client; import { testSdkFunctions } from /inngest/sdk_function; import { testSdkSteps } from /inngest/sdk_step_test; import { testCancel } from /inngest/sdk_cancel_test; import { testRetry } from /inngest/sdk_retry_test; import { testNonRetriableError } from /inngest/non_retryable; import { testParallelism } from /inngest/sdk_parallel_test; import { testWaitForEvent } from /inngest/sdk_wait_for_event_test; export default serve({ client: inngest, functions: [ testSdkFunctions, testSdkSteps, testCancel, testRetry, testNonRetriableError, testParallelism, testWaitForEvent, ], });serve()来自inngest/next它导出的默认函数即 Next.js 的 pages 路由处理器负责响应 Inngest 服务端的两个动作GET 内省服务端拉取函数清单与POST 执行按步骤协议调用函数。七个测试函数分别对应 tests/js/src/inngest/ 目录下的独立文件基础函数sdk_function.ts、步骤sdk_step_test.ts、取消sdk_cancel_test.ts、重试sdk_retry_test.ts、不可重试错误non_retryable.ts、并行sdk_parallel_test.ts、等待事件sdk_wait_for_event_test.ts。其中最简单的示例 tests/js/src/inngest/sdk_function.ts 展示了标准的 v3 函数写法import { inngest } from /inngest/client; export const testSdkFunctions inngest.createFunction( { id: simple-fn }, { event: tests/function.test }, async ({ event }) { return { name: event.name, body: ok }; } );客户端实例定义在 tests/js/src/inngest/client.ts仅一行new Inngest({ id: test-suite })。该idtest-suite会被 Go 侧测试用来拼接断言 ID例如 tests/sdk_function_test.go 中的ID: test-suite-simple-fn。/api/introspect函数配置的静态导出tests/js/src/pages/api/introspect.ts 遍历上述七个函数调用各自的getConfig(new URL(http://127.0.0.1:3000/api/inngest), test-suite)并把第一个元素收集成 JSON 数组返回。这条端点允许测试脚本不经过完整握手流程直接检查函数注册产出的配置触发器、ID、步骤结构等是注册正确性的低成本验证通道。下一代 SDK 的 Durable Endpointtests/js同时承担 v4 SDK 的 Durable Endpoint 测试。客户端定义在 tests/js/src/inngest/client_v4.tsimport { Inngest } from inngest-v4; import { endpointAdapter } from inngest-v4/next; export const inngestV4 new Inngest({ id: test-suite-v4, endpointAdapter, isDev: true, baseUrl: process.env.INNGEST_BASE_URL ?? http://127.0.0.1:8288, });这里有三处值得注意endpointAdapter来自inngest-v4/next表明 v4 走的是 App Router 的Route Handler而非 pages 路由isDev: true与baseUrl默认指向本机开发服务器127.0.0.1:8288可用环境变量INNGEST_BASE_URL覆盖。对应的路由位于 App Router 的src/app/api/durable/下tests/js/src/app/api/durable/sync/route.tsPOST inngestV4.endpoint(...)直接同步返回{hello:world}验证最简单的 durable 请求tests/js/src/app/api/durable/async/route.ts先执行await step.sleep(brief-pause, 1s)再返回{hello:async}模拟一个需要挂起再恢复的异步工作流。这两个路由与 docs/durable-endpoints/streaming.md 所描述的 durable endpoint 机制相配套为 Go 侧的 tests/sdk_durable_endpoint_test.go 提供被测端点。在仓库测试流程中的角色tests.sh 全链路调度README 只讲了如何手动启动应用而仓库根目录的 tests.sh 揭示了它的完整自动化用法。关键流程如下安装并后台启动 JS 测试应用tests.sh 第 45–46 行附近sh -c cd ./tests/js pnpm install --frozen-lockfile /dev/null 2 /dev/null sh -c cd ./tests/js pnpm dev /dev/null 2 /dev/null --frozen-lockfile保证安装与 tests/js/pnpm-lock.yaml 完全一致——这也是 pnpm 工作流而非 npm/yarn 的进一步佐证。启动 Inngest 开发服务器go run ./cmd dev --no-discovery随后以最多 10 次、每次重试的循环轮询http://127.0.0.1:8288/health直到开发服务器健康为止。Go 测试驱动器指向该应用tests/main.go 通过环境变量约定两个地址——ENV_SDK_URL SDK_URL // eg. http://127.0.0.1:3000/api/inngest ENV_API_URL API_URL // eg http://127.0.0.1:8288 或线上 API ENV_EVENT_URL EVENT_URL ENV_SIGNING_KEY / ENV_EVENT_KEY / ENV_PROXY_URL ...SDK_URL的示例值正是tests/js的/api/inngest端点API_URL则指向 8288 端口的开发服务器。以 tests/sdk_function_test.go 为例测试发送tests/function.test事件并断言函数注册可被 GET 处理器内省、被服务端正确注册、响应事件触发并返回预期数据注释中直接写明这是跨 SDK 的行为验证。Conformance 用例复用同一地址tests/conformance/golang/inngest.conformance.yaml 声明了serve传输与六个用例serve-introspection、basic-invoke、steps-serial、retry-basic、cancel-basic、wait-for-event-basic其sdk.url为http://127.0.0.1:3000/api/inngest、dev.url为http://127.0.0.1:8288与 JS 测试应用占用的端口和路由完全一致。同一套用例的 Go 侧被测实现见 tests/conformance/golang/main.go同样默认监听127.0.0.1:3000——从源码结构看JS 应用与 Go conformance 应用是同一组用例在不同 SDK 上的平行被测体。安全策略pnpm 的 minimum-release-age 加固这是 README 中最具仓库特色的部分原文档明确给出了安全约定现结合仓库实际配置展开。tests/js/.npmrc 的完整内容只有两行enable-pre-post-scriptsfalse minimum-release-age1440逐条解读配置项取值作用minimum-release-age1440分钟即 24 小时pnpm 安装依赖时会拒绝安装发布距今不足 1440 分钟的包版本。攻击者若发布了一个恶意版本需要等待 24 小时观察期后才能进入依赖树为人工审计与上游撤包争取时间窗口enable-pre-post-scriptsfalse禁用第三方依赖的 pre/post 安装脚本这是 pnpm 针对安装脚本供应链攻击面的加固开关package.json中声明的packageManager与pnpm.overrides钉死的postcss、protobufjs等版本是与之配套的组合拳README 还补充了一条运维口径如果某个特定包确实需要绕过观察期可用minimum-release-age-exclude配置对该包单独豁免而不是全局降低minimum-release-age。这一白名单豁免优于全局放宽的原则是依赖供应链安全中典型的纵深防御做法。需要说明适用前提minimum-release-age由 pnpm 在锁文件重新解析时生效仓库用pnpm install --frozen-lockfile见 tests.sh做 CI 安装此时以已提交的 tests/js/pnpm-lock.yaml 为准该加固主要保护的是开发者本地安装与锁文件更新时引入的新依赖。部署说明与小结README 保留了 Next.js 模板的部署章节该应用可以通过 Vercel 平台一键部署也可按 Next.js 官方部署文档自行配置。就本仓库的实际用途而言tests/js几乎总在本地pnpm dev模式下与go run ./cmd dev的开发服务器8288 端口配对运行部署到外部平台并非其常规使用场景client_v4.ts中INNGEST_BASE_URL环境变量正是为切换目标服务端留的口子。小结一下tests/js的三个关键事实与对应证据它是 JS SDKv3 预发布版与 v4 正式版并行的集成测试床通过 tests/js/src/pages/api/inngest.ts 的serve()暴露七个测试函数供 tests/sdk_function_test.go 等 Go 测试驱动它是仓库 CI 的一部分由 tests.sh 以pnpm install --frozen-lockfilepnpm dev后台启动端口 3000 与 8288 开发服务器握手它示范了 pnpm 供应链加固tests/js/.npmrc 的minimum-release-age1440与enable-pre-post-scriptsfalse配合 tests/js/package.json 的pnpm.overrides版本钉死构成完整的依赖攻击面收敛策略。【免费下载链接】inngestThe leading workflow orchestration platform. Run stateful step functions and AI workflows on serverless, servers, or the edge.项目地址: https://gitcode.com/GitHub_Trending/in/inngest创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Inngest JS 测试应用实战：Next.js SDK 集成测试床与 pnpm 供应链加固
Inngest JS 测试应用实战Next.js SDK 集成测试床与 pnpm 供应链加固【免费下载链接】inngestThe leading workflow orchestration platform. Run stateful step functions and AI workflows on serverless, servers, or the edge.项目地址: https://gitcode.com/GitHub_Trending/in/inngest本文以 Inngest 仓库中 tests/js/README.md 为核心讲解tests/js这个 Next.js 测试应用如何作为 JS SDK 的集成测试床运行如何启动开发服务器、/api/inngest端点如何注册与暴露测试函数、.npmrc中minimum-release-age如何加固供应链以及该应用如何被仓库根目录的tests.sh与 Go 测试驱动器整体调度。读完后你能独立跑起这个测试应用并理解它在整个 Inngest 服务端集成测试体系中的角色与安全策略设计。应用定位一个专为 SDK 集成测试服务的 Next.js 应用tests/js是一个由create-next-app引导的 Next.js 项目见 tests/js/README.md 开头声明其package.json中名为inngest-js-tests并声明了packageManager: pnpm10.18.2。它不是面向最终用户的产品应用而是承载 Inngest JS SDK 测试函数、供仓库内 Go 测试代码tests/目录下的sdk_*_test.go系列跨进程调用的活体测试目标。从 tests/js/package.json 的依赖声明可以看出其测试床的关键设计——同时引入两代 JS SDK{ name: inngest-js-tests, private: true, packageManager: pnpm10.18.2, scripts: { dev: next dev, build: next build, start: next start, lint: next lint }, dependencies: { inngest: 3.11.1-pr-411.4, inngest-v4: npm:inngest4.3.0, zod: ^3.25.0, next: 15.5.18, react: 18.2.0, typescript: 5.6.3, ...: ... }, pnpm: { overrides: { inngest4zod: 3.25.76, postcss: 8.5.10, protobufjs7: 7.5.8, protobufjs8: 8.2.0, serialize-error-cjs: 0.1.3 } } }inngest依赖指向一个 PR 预发布版本3.11.1-pr-411.4用于测试在研的 v3 分支行为inngest-v4通过 pnpm 的npm:别名映射到正式发布的inngest4.3.0代表下一代 SDKpnpm.overrides把两棵依赖树中的zod、postcss、protobufjs等传递依赖强制钉死到特定版本。从源码结构看这些固定值是为了让 v3 与 v4 两个 SDK 版本能在同一个应用内共存且不发生依赖冲突同时锁定已出现漏洞的传递依赖版本。配套的构建配置见 tests/js/next.config.js其中开启了experimental.appDir: truetests/js/tsconfig.json 使用严格模式strict: true并通过路径别名把/*映射到./src/*代码中的/inngest/client等导入即依赖该映射。快速启动开发服务器README 给出的标准启动方式继承自原文档npm run dev # or yarn dev # or pnpm dev由于packageManager字段与pnpm-lock.yaml的存在推荐且仓库 CI 脚本实际使用的就是pnpm。启动后访问http://localhost:3000即可看到应用。README 中提到修改app/page.tsx即可编辑页面且页面支持热更新pages/api目录整体映射到/api/*目录中的文件按 API 路由处理而非 React 页面处理。需要注意两点仓库现状当前src/app下并没有page.tsx页面文件只有 API 路由见下文核心端点一节页面编辑相关描述属于create-next-app模板的通用说明README 提到的/api/hello同样是模板遗留示例仓库中真实存在的 API 路由是src/pages/api/下的 inngest.ts 与 introspect.ts。README 还说明该项目通过next/font自动优化加载 Inter 字体这与 tests/js/package.json 中的next/font依赖相互印证。核心端点serve 处理器与 introspect 探测/api/inngest函数注册与执行入口tests/js/src/pages/api/inngest.ts 是整个测试床的心脏import { serve } from inngest/next; import { inngest } from /inngest/client; import { testSdkFunctions } from /inngest/sdk_function; import { testSdkSteps } from /inngest/sdk_step_test; import { testCancel } from /inngest/sdk_cancel_test; import { testRetry } from /inngest/sdk_retry_test; import { testNonRetriableError } from /inngest/non_retryable; import { testParallelism } from /inngest/sdk_parallel_test; import { testWaitForEvent } from /inngest/sdk_wait_for_event_test; export default serve({ client: inngest, functions: [ testSdkFunctions, testSdkSteps, testCancel, testRetry, testNonRetriableError, testParallelism, testWaitForEvent, ], });serve()来自inngest/next它导出的默认函数即 Next.js 的 pages 路由处理器负责响应 Inngest 服务端的两个动作GET 内省服务端拉取函数清单与POST 执行按步骤协议调用函数。七个测试函数分别对应 tests/js/src/inngest/ 目录下的独立文件基础函数sdk_function.ts、步骤sdk_step_test.ts、取消sdk_cancel_test.ts、重试sdk_retry_test.ts、不可重试错误non_retryable.ts、并行sdk_parallel_test.ts、等待事件sdk_wait_for_event_test.ts。其中最简单的示例 tests/js/src/inngest/sdk_function.ts 展示了标准的 v3 函数写法import { inngest } from /inngest/client; export const testSdkFunctions inngest.createFunction( { id: simple-fn }, { event: tests/function.test }, async ({ event }) { return { name: event.name, body: ok }; } );客户端实例定义在 tests/js/src/inngest/client.ts仅一行new Inngest({ id: test-suite })。该idtest-suite会被 Go 侧测试用来拼接断言 ID例如 tests/sdk_function_test.go 中的ID: test-suite-simple-fn。/api/introspect函数配置的静态导出tests/js/src/pages/api/introspect.ts 遍历上述七个函数调用各自的getConfig(new URL(http://127.0.0.1:3000/api/inngest), test-suite)并把第一个元素收集成 JSON 数组返回。这条端点允许测试脚本不经过完整握手流程直接检查函数注册产出的配置触发器、ID、步骤结构等是注册正确性的低成本验证通道。下一代 SDK 的 Durable Endpointtests/js同时承担 v4 SDK 的 Durable Endpoint 测试。客户端定义在 tests/js/src/inngest/client_v4.tsimport { Inngest } from inngest-v4; import { endpointAdapter } from inngest-v4/next; export const inngestV4 new Inngest({ id: test-suite-v4, endpointAdapter, isDev: true, baseUrl: process.env.INNGEST_BASE_URL ?? http://127.0.0.1:8288, });这里有三处值得注意endpointAdapter来自inngest-v4/next表明 v4 走的是 App Router 的Route Handler而非 pages 路由isDev: true与baseUrl默认指向本机开发服务器127.0.0.1:8288可用环境变量INNGEST_BASE_URL覆盖。对应的路由位于 App Router 的src/app/api/durable/下tests/js/src/app/api/durable/sync/route.tsPOST inngestV4.endpoint(...)直接同步返回{hello:world}验证最简单的 durable 请求tests/js/src/app/api/durable/async/route.ts先执行await step.sleep(brief-pause, 1s)再返回{hello:async}模拟一个需要挂起再恢复的异步工作流。这两个路由与 docs/durable-endpoints/streaming.md 所描述的 durable endpoint 机制相配套为 Go 侧的 tests/sdk_durable_endpoint_test.go 提供被测端点。在仓库测试流程中的角色tests.sh 全链路调度README 只讲了如何手动启动应用而仓库根目录的 tests.sh 揭示了它的完整自动化用法。关键流程如下安装并后台启动 JS 测试应用tests.sh 第 45–46 行附近sh -c cd ./tests/js pnpm install --frozen-lockfile /dev/null 2 /dev/null sh -c cd ./tests/js pnpm dev /dev/null 2 /dev/null --frozen-lockfile保证安装与 tests/js/pnpm-lock.yaml 完全一致——这也是 pnpm 工作流而非 npm/yarn 的进一步佐证。启动 Inngest 开发服务器go run ./cmd dev --no-discovery随后以最多 10 次、每次重试的循环轮询http://127.0.0.1:8288/health直到开发服务器健康为止。Go 测试驱动器指向该应用tests/main.go 通过环境变量约定两个地址——ENV_SDK_URL SDK_URL // eg. http://127.0.0.1:3000/api/inngest ENV_API_URL API_URL // eg http://127.0.0.1:8288 或线上 API ENV_EVENT_URL EVENT_URL ENV_SIGNING_KEY / ENV_EVENT_KEY / ENV_PROXY_URL ...SDK_URL的示例值正是tests/js的/api/inngest端点API_URL则指向 8288 端口的开发服务器。以 tests/sdk_function_test.go 为例测试发送tests/function.test事件并断言函数注册可被 GET 处理器内省、被服务端正确注册、响应事件触发并返回预期数据注释中直接写明这是跨 SDK 的行为验证。Conformance 用例复用同一地址tests/conformance/golang/inngest.conformance.yaml 声明了serve传输与六个用例serve-introspection、basic-invoke、steps-serial、retry-basic、cancel-basic、wait-for-event-basic其sdk.url为http://127.0.0.1:3000/api/inngest、dev.url为http://127.0.0.1:8288与 JS 测试应用占用的端口和路由完全一致。同一套用例的 Go 侧被测实现见 tests/conformance/golang/main.go同样默认监听127.0.0.1:3000——从源码结构看JS 应用与 Go conformance 应用是同一组用例在不同 SDK 上的平行被测体。安全策略pnpm 的 minimum-release-age 加固这是 README 中最具仓库特色的部分原文档明确给出了安全约定现结合仓库实际配置展开。tests/js/.npmrc 的完整内容只有两行enable-pre-post-scriptsfalse minimum-release-age1440逐条解读配置项取值作用minimum-release-age1440分钟即 24 小时pnpm 安装依赖时会拒绝安装发布距今不足 1440 分钟的包版本。攻击者若发布了一个恶意版本需要等待 24 小时观察期后才能进入依赖树为人工审计与上游撤包争取时间窗口enable-pre-post-scriptsfalse禁用第三方依赖的 pre/post 安装脚本这是 pnpm 针对安装脚本供应链攻击面的加固开关package.json中声明的packageManager与pnpm.overrides钉死的postcss、protobufjs等版本是与之配套的组合拳README 还补充了一条运维口径如果某个特定包确实需要绕过观察期可用minimum-release-age-exclude配置对该包单独豁免而不是全局降低minimum-release-age。这一白名单豁免优于全局放宽的原则是依赖供应链安全中典型的纵深防御做法。需要说明适用前提minimum-release-age由 pnpm 在锁文件重新解析时生效仓库用pnpm install --frozen-lockfile见 tests.sh做 CI 安装此时以已提交的 tests/js/pnpm-lock.yaml 为准该加固主要保护的是开发者本地安装与锁文件更新时引入的新依赖。部署说明与小结README 保留了 Next.js 模板的部署章节该应用可以通过 Vercel 平台一键部署也可按 Next.js 官方部署文档自行配置。就本仓库的实际用途而言tests/js几乎总在本地pnpm dev模式下与go run ./cmd dev的开发服务器8288 端口配对运行部署到外部平台并非其常规使用场景client_v4.ts中INNGEST_BASE_URL环境变量正是为切换目标服务端留的口子。小结一下tests/js的三个关键事实与对应证据它是 JS SDKv3 预发布版与 v4 正式版并行的集成测试床通过 tests/js/src/pages/api/inngest.ts 的serve()暴露七个测试函数供 tests/sdk_function_test.go 等 Go 测试驱动它是仓库 CI 的一部分由 tests.sh 以pnpm install --frozen-lockfilepnpm dev后台启动端口 3000 与 8288 开发服务器握手它示范了 pnpm 供应链加固tests/js/.npmrc 的minimum-release-age1440与enable-pre-post-scriptsfalse配合 tests/js/package.json 的pnpm.overrides版本钉死构成完整的依赖攻击面收敛策略。【免费下载链接】inngestThe leading workflow orchestration platform. Run stateful step functions and AI workflows on serverless, servers, or the edge.项目地址: https://gitcode.com/GitHub_Trending/in/inngest创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考