feat: index json schemas on tasks and schemaTask #2351
Conversation
This change introduces support for handling payload schemas during task indexing. By incorporating the `payloadSchema` attribute into various components, we ensure that each task's payload structure is clearly defined and can be validated before processing. - Updated the TaskManifest and task metadata structures to include an optional `payloadSchema` attribute. This addition allows for more robust validation and handling of task payloads. - Enhanced several core modules to export and utilize the new `getSchemaToJsonSchema` function, providing easier conversion of schema types to JSON schemas. - Modified the database schema to store the `payloadSchema` attribute, ensuring that the payload schema information is persisted. - The change helps in maintaining consistency in data handling and improves the integrity of task data across the application.
The `getSchemaToJsonSchema` function was removed and replaced with `schemaToJsonSchema` across the codebase. This update introduces a new `@trigger.dev/schema-to-json` package to handle conversions of schema validation libraries to JSON Schema format, centralizing the functionality and improving maintainability. - Removed `getSchemaToJsonSchema` exports and references. - Added new schema conversion utility `@trigger.dev/schema-to-json`. - Updated `trigger-sdk` package to utilize `schemaToJsonSchema` for payloads. - Extensive testing coverage included to ensure conversion accuracy across various schema libraries including Zod, Yup, ArkType, Effect, and TypeBox. - The update ensures consistent and reliable schema conversions, facilitating future enhancements and supporting additional schema libraries.
This change enhances the schema-to-json package by adding support for Zod version 4, which introduces the native `toJsonSchema` method. This method facilitates a direct conversion of Zod schemas to JSON Schema format, improving performance and reducing reliance on the `zod-to-json-schema` library. - Updated README to reflect Zod 4 support with native method and retained support for Zod 3 via existing library. - Modified package.json to allow installation of both Zod 3 and 4 versions. - Implemented handling for Zod 4 schemas in `src/index.ts` using their native method. - Added a test case to verify the proper conversion of Zod 4 schemas to JSON Schema. - Included a script for updating the package version based on the root package.json. - Introduced a specific TypeScript config for source files.
The package @trigger.dev/schema-to-json has been revised to ensure bundle safety by removing direct dependencies on schema libraries such as Zod, Yup, and Effect. This change minimizes bundle size and enhances tree-shaking by allowing external conversion libraries to be utilized only at runtime if necessary. As a result, the README was updated to reflect this usage pattern. - Introduced `initializeSchemaConverters` function to load necessary conversion libraries at runtime, keeping the base package slim. - Adjusted test suite to initialize converters before tests, ensuring accurate testing of schema conversion capabilities. - Updated `schemaToJsonSchema` function to dynamically check for availability of conversion libraries, improving flexibility without increasing the package size. - Added configuration files for Vitest to support the new testing framework, reflecting the transition from previous test setups. These enhancements ensure that only the schema libraries actively used in an application are bundled, optimizing performance and resource usage.
The changes introduce stricter typing for JSON Schema-related definitions, specifically replacing vague types with more precise ones, such as using `z.record(z.unknown())` instead of `z.any()` and `Record<string, unknown>` in place of `any`. This is part of an effort to better align with common practices and improve type safety in the packages. - Updated the `payloadSchema` in several files to use `z.record(z.unknown())`, enhancing the type strictness and consistency with JSON Schema Draft 7 recommendations. - Added `@types/json-schema` as a dependency, utilizing its definitions for improved type clarity and adherence to best practices in TypeScript. - Modified various comments to explicitly mention JSON Schema Draft 7, ensuring developers are aware of the JSON Schema version being implemented. - These adjustments are informed by research into how popular libraries and tools handle JSON Schema typing, aiming to integrate best practices for improved maintainability and interoperability.
The change introduces extensive examples of using JSON Schemas in the 'references/hello-world' project within the 'trigger.dev' repository. These examples utilize libraries like Zod, Yup, and TypeBox for JSON Schema conversion and validation. The new examples demonstrate different use cases, including automatic conversion with schemaTask, manual schema provision, and schema conversion at build time. We also updated the dependencies in 'package.json' to include the necessary libraries for schema conversion and validation. - Included examples of processing tasks with JSON Schema using libraries such as Zod, Yup, TypeBox, and ArkType. - Showcased schema conversion techniques and type-safe JSON Schema creation. - Updated 'package.json' to ensure all necessary dependencies for schema operations are available. - Created illustrative scripts that cover task management from user processing to complex schema implementations.
The previous implementation required users to directly import and initialize functions from the `@trigger.dev/schema-to-json` package, which was not the intended user experience. This change refactors the SDK so that all necessary functions and types from `@trigger.dev/schema-to-json` are encapsulated within the `@trigger.dev/*` packages. - The examples in `usage.ts` have been updated to clearly mark `@trigger.dev/schema-to-json` as an internal-only package. - Re-export JSON Schema types and conversions in the SDK to improve developer experience (DX). - Removed unnecessary direct dependencies on `@trigger.dev/schema-to-json` from user-facing code, ensuring initialization and conversion logic is handled internally. - Replaced instances where users were required to manually perform schema conversions with automatic handling within the SDK for simplification and better maintainability.
The change was necessary to improve type safety by using a proper JSONSchema type definition instead of a generic Record<string, unknown>. This enhances the developer experience and ensures that task payloads conform to the JSON Schema Draft 7 specification. The JSONSchema type is now re-exported from the SDK for user convenience, hiding internal complexity and maintaining a seamless developer experience. - Added JSONSchema type based on Draft 7 specification - Updated task metadata and options to use JSONSchema type - Hid internal schema conversion logic from users by re-exporting types from SDK - Improved bundle safety and dependency management
This commit introduces a comprehensive set of JSON schema testing within the monorepo, specifically adding a new test project in `references/json-schema-test`. This includes a variety of schema definitions and tasks utilizing multiple validation libraries to ensure robust type-checking and runtime validation. Additionally, the dependency versions for `@effect/schema` have been adjusted from `^0.76.5` to `^0.75.5` to maintain compatibility across the project components. This ensures consistent behavior and compatibility with existing code bases without introducing breaking changes or unexpected behavior due to version discrepancies. Key updates include: - Added new test project with extensive schema validation tests. - Ensured type safety across various task implementations. - Reverted dependency versions to ensure compatibility. - Created multiple schema tasks using libraries like Zod, Yup, and others for thorough testing.
Whitespace and formatting changes were applied across the `json-schema-test` reference project to enhance code readability and cohesion. This included removing unnecessary trailing spaces and ensuring consistent indentation patterns, which improves maintainability and readability by following the project's code style guidelines. - Renamed JSONSchema type annotations to adhere to TypeScript conventions, ensuring that all schema definitions properly satisfy the JSONSchema interface. - Restructured some object declarations for improved clarity, especially within complex schema definitions. - These adjustments are crucial for better future maintainability, reducing potential developer errors when interacting with these test schemas.
|
WalkthroughThis change set introduces a new package, Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes
Note ⚡️ Unit Test Generation is now available in beta!Learn more here, or try it out under "Finishing Touches" below. 📜 Recent review detailsConfiguration used: CodeRabbit UI ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (1)
✅ Files skipped from review due to trivial changes (1)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (23)
✨ Finishing Touches🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 6
♻️ Duplicate comments (1)
packages/cli-v3/src/entryPoints/managed-index-worker.ts (1)
201-216: Apply the same error handling improvements as dev-index-worker.This function has identical logic to the one in
dev-index-worker.tsand would benefit from the same error handling improvements to prevent indexing failures due to schema conversion errors.Apply the same error handling pattern suggested for
dev-index-worker.ts:async function convertSchemasToJsonSchemas(tasks: TaskManifest[]): Promise<TaskManifest[]> { await initializeSchemaConverters(); const convertedTasks = tasks.map((task) => { + try { const schema = resourceCatalog.getTaskSchema(task.id); if (schema) { const result = schemaToJsonSchema(schema); return { ...task, payloadSchema: result?.jsonSchema }; } + } catch (error) { + console.warn(`Failed to convert schema for task ${task.id}:`, error); + } return task; }); return convertedTasks; }
🧹 Nitpick comments (7)
internal-packages/database/prisma/migrations/20250730084611_add_payload_schema_to_background_worker_task/migration.sql (1)
1-2: Missing index for JSONB look-upsIf
payloadSchemawill ever be queried (e.g.,WHERE payloadSchema ? 'properties'), add a GIN index now to avoid a later full-table rewrite:-- Optional but highly recommended CREATE INDEX CONCURRENTLY "BackgroundWorkerTask_payloadSchema_gin" ON "BackgroundWorkerTask" USING gin ("payloadSchema" jsonb_path_ops);internal-packages/database/prisma/schema.prisma (1)
513-514: Consider JSONB size/indexing implications forpayloadSchema.Storing full JSON Schemas inline can inflate row size; frequent
SELECT * FROM BackgroundWorkerTaskcalls will now pull the entire schema blob even when not needed. Two suggestions:
- Add a dedicated index when queries will filter by specific JSON paths (e.g. version).
- If the schema is rarely read, a separate table keyed by
(taskId, version)would keep the hot path leaner.Not blocking, but worth double-checking with the query profile before this hits prod.
apps/webapp/app/v3/services/createBackgroundWorker.server.ts (2)
80-80: Consider stronger typing instead ofas any.The type assertion to
anybypasses TypeScript's type safety. Consider using proper Prisma JSON field typing or a more specific type assertion if there's a known type mismatch.If this is due to Prisma JSON field typing issues, consider defining a proper type for the metadata field or investigate if the Prisma schema can be updated to provide better typing.
283-283: Consider stronger typing instead ofas any.The type assertion to
anyforpayloadSchemareduces type safety. Since this is part of the JSON Schema functionality, consider using a more specific type likeJSONSchemaorPrisma.JsonValueinstead ofany.This could potentially be typed as:
- payloadSchema: task.payloadSchema as any, + payloadSchema: task.payloadSchema as Prisma.JsonValue,Or if
JSONSchematype is available:- payloadSchema: task.payloadSchema as any, + payloadSchema: task.payloadSchema as JSONSchema,packages/core/src/v3/types/jsonSchema.ts (1)
5-67: Consider using type instead of interface per coding guidelines.The JSONSchema definition is comprehensive and well-structured, covering all major JSON Schema Draft 7 features. However, according to the coding guidelines, "For TypeScript, we usually use types over interfaces."
Consider converting the interface to a type:
-export interface JSONSchema { +export type JSONSchema = { $id?: string; $ref?: string; $schema?: string; $comment?: string; // ... rest of the properties [key: string]: any; -} +};This would align with the project's TypeScript conventions while maintaining the same functionality.
packages/schema-to-json/src/index.ts (2)
94-96: Consider improving type safety for globalThis converters.The current implementation uses multiple
@ts-ignorecomments when accessing globalThis properties. Consider defining a proper type for the global converters to improve type safety and maintainability.Add type definitions at the top of the file:
declare global { var __zodToJsonSchema: typeof import("zod-to-json-schema") | undefined; var __yupToJsonSchema: typeof import("@sodaru/yup-to-json-schema") | undefined; var __effectJsonSchema: { JSONSchema: any } | undefined; }This would eliminate the need for
@ts-ignorecomments and provide better IntelliSense support.Also applies to: 128-130, 152-154, 182-182, 189-189, 204-204, 236-241
179-209: Consider adding initialization state tracking.The
initializeSchemaConvertersfunction could be called multiple times concurrently, potentially causing redundant imports. Consider tracking initialization state to prevent duplicate work.+let initializationPromise: Promise<void> | undefined; + export async function initializeSchemaConverters(): Promise<void> { + if (initializationPromise) { + return initializationPromise; + } + + initializationPromise = (async () => { try { // @ts-ignore globalThis.__zodToJsonSchema = await import("zod-to-json-schema"); } catch { // Zod conversion not available } // ... rest of the imports + })(); + + return initializationPromise; }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (17)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yamlreferences/hello-world/package.jsonis excluded by!references/**references/hello-world/src/trigger/example.tsis excluded by!references/**references/hello-world/src/trigger/jsonSchema.tsis excluded by!references/**references/hello-world/src/trigger/jsonSchemaApi.tsis excluded by!references/**references/hello-world/src/trigger/jsonSchemaSimple.tsis excluded by!references/**references/json-schema-test/README.mdis excluded by!references/**references/json-schema-test/package.jsonis excluded by!references/**references/json-schema-test/src/trigger/core-functionality-test.tsis excluded by!references/**references/json-schema-test/src/trigger/simple-type-test.tsis excluded by!references/**references/json-schema-test/src/trigger/test-batch-operations.tsis excluded by!references/**references/json-schema-test/src/trigger/test-other-schemas.tsis excluded by!references/**references/json-schema-test/src/trigger/test-yup.tsis excluded by!references/**references/json-schema-test/src/trigger/test-zod.tsis excluded by!references/**references/json-schema-test/trigger.config.tsis excluded by!references/**references/json-schema-test/tsconfig.jsonis excluded by!references/**references/json-schema-test/type-test.tsis excluded by!references/**
📒 Files selected for processing (30)
apps/webapp/app/v3/services/createBackgroundWorker.server.ts(2 hunks)apps/webapp/app/v3/services/createDeploymentBackgroundWorkerV3.server.ts(1 hunks)apps/webapp/app/v3/services/createDeploymentBackgroundWorkerV4.server.ts(1 hunks)internal-packages/database/prisma/migrations/20250730084611_add_payload_schema_to_background_worker_task/migration.sql(1 hunks)internal-packages/database/prisma/schema.prisma(1 hunks)packages/cli-v3/package.json(1 hunks)packages/cli-v3/src/entryPoints/dev-index-worker.ts(3 hunks)packages/cli-v3/src/entryPoints/managed-index-worker.ts(3 hunks)packages/core/src/v3/resource-catalog/catalog.ts(2 hunks)packages/core/src/v3/resource-catalog/index.ts(2 hunks)packages/core/src/v3/resource-catalog/noopResourceCatalog.ts(2 hunks)packages/core/src/v3/resource-catalog/standardResourceCatalog.ts(3 hunks)packages/core/src/v3/schemas/resources.ts(1 hunks)packages/core/src/v3/schemas/schemas.ts(1 hunks)packages/core/src/v3/types/index.ts(1 hunks)packages/core/src/v3/types/jsonSchema.ts(1 hunks)packages/core/src/v3/types/tasks.ts(4 hunks)packages/schema-to-json/.gitignore(1 hunks)packages/schema-to-json/README.md(1 hunks)packages/schema-to-json/package.json(1 hunks)packages/schema-to-json/src/index.ts(1 hunks)packages/schema-to-json/src/tests/index.test.ts(1 hunks)packages/schema-to-json/tsconfig.json(1 hunks)packages/schema-to-json/tsconfig.src.json(1 hunks)packages/schema-to-json/tsconfig.test.json(1 hunks)packages/schema-to-json/vitest.config.ts(1 hunks)packages/trigger-sdk/package.json(1 hunks)packages/trigger-sdk/src/v3/index.ts(1 hunks)packages/trigger-sdk/src/v3/schemas.ts(1 hunks)packages/trigger-sdk/src/v3/shared.ts(4 hunks)
🧰 Additional context used
📓 Path-based instructions (5)
**/*.{ts,tsx}
📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)
**/*.{ts,tsx}: Always prefer using isomorphic code like fetch, ReadableStream, etc. instead of Node.js specific code
For TypeScript, we usually use types over interfaces
Avoid enums
No default exports, use function declarations
Files:
apps/webapp/app/v3/services/createDeploymentBackgroundWorkerV4.server.tspackages/core/src/v3/schemas/resources.tsapps/webapp/app/v3/services/createDeploymentBackgroundWorkerV3.server.tspackages/trigger-sdk/src/v3/schemas.tspackages/core/src/v3/schemas/schemas.tspackages/core/src/v3/types/index.tspackages/core/src/v3/resource-catalog/catalog.tspackages/core/src/v3/resource-catalog/noopResourceCatalog.tspackages/trigger-sdk/src/v3/index.tspackages/core/src/v3/resource-catalog/index.tspackages/schema-to-json/vitest.config.tspackages/core/src/v3/types/tasks.tspackages/trigger-sdk/src/v3/shared.tspackages/core/src/v3/resource-catalog/standardResourceCatalog.tspackages/cli-v3/src/entryPoints/dev-index-worker.tspackages/schema-to-json/src/index.tspackages/cli-v3/src/entryPoints/managed-index-worker.tspackages/schema-to-json/src/tests/index.test.tsapps/webapp/app/v3/services/createBackgroundWorker.server.tspackages/core/src/v3/types/jsonSchema.ts
{packages/core,apps/webapp}/**/*.{ts,tsx}
📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)
We use zod a lot in packages/core and in the webapp
Files:
apps/webapp/app/v3/services/createDeploymentBackgroundWorkerV4.server.tspackages/core/src/v3/schemas/resources.tsapps/webapp/app/v3/services/createDeploymentBackgroundWorkerV3.server.tspackages/core/src/v3/schemas/schemas.tspackages/core/src/v3/types/index.tspackages/core/src/v3/resource-catalog/catalog.tspackages/core/src/v3/resource-catalog/noopResourceCatalog.tspackages/core/src/v3/resource-catalog/index.tspackages/core/src/v3/types/tasks.tspackages/core/src/v3/resource-catalog/standardResourceCatalog.tsapps/webapp/app/v3/services/createBackgroundWorker.server.tspackages/core/src/v3/types/jsonSchema.ts
apps/webapp/**/*.{ts,tsx}
📄 CodeRabbit Inference Engine (.cursor/rules/webapp.mdc)
apps/webapp/**/*.{ts,tsx}: In the webapp, all environment variables must be accessed through theenvexport ofenv.server.ts, instead of directly accessingprocess.env.
When importing from@trigger.dev/corein the webapp, never import from the root@trigger.dev/corepath; always use one of the subpath exports as defined in the package's package.json.
Files:
apps/webapp/app/v3/services/createDeploymentBackgroundWorkerV4.server.tsapps/webapp/app/v3/services/createDeploymentBackgroundWorkerV3.server.tsapps/webapp/app/v3/services/createBackgroundWorker.server.ts
**/tsconfig.json
📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)
Use strict mode
Files:
packages/schema-to-json/tsconfig.json
**/*.test.{ts,tsx}
📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)
Our tests are all vitest
Files:
packages/schema-to-json/src/tests/index.test.ts
🧠 Learnings (32)
📓 Common learnings
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : When implementing schema tasks, use `schemaTask` from `trigger.dev/sdk/v3` and validate payloads as shown.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : ALWAYS generate Trigger.dev tasks using the `task` function from `trigger.dev/sdk/v3` and export them as shown in the correct pattern.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : When implementing scheduled (cron) tasks, use `schedules.task` from `trigger.dev/sdk/v3` and follow the shown patterns.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : You MUST use `trigger.dev/sdk/v3` when writing Trigger.dev tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : If you are able to generate an example payload for a task, do so.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : When triggering a task from backend code, use `tasks.trigger`, `tasks.batchTrigger`, or `tasks.triggerAndPoll` as shown in the examples.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
Learning: Before generating any code for Trigger.dev tasks, verify: (1) Are you importing from `trigger.dev/sdk/v3`? (2) Have you exported every task? (3) Have you generated any deprecated code patterns?
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : When using metadata in tasks, use the `metadata` API as shown, and only inside run functions or task lifecycle hooks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : When using retry, queue, machine, or maxDuration options, configure them as shown in the examples for Trigger.dev tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
Learning: Applies to trigger.config.ts : Build extensions such as `additionalFiles`, `additionalPackages`, `aptGet`, `emitDecoratorMetadata`, `prismaExtension`, `syncEnvVars`, `puppeteer`, `ffmpeg`, and `esbuildPlugin` must be configured in `trigger.config.ts` as shown.
📚 Learning: applies to **/trigger/**/*.{ts,tsx,js,jsx} : when using metadata in tasks, use the `metadata` api as...
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : When using metadata in tasks, use the `metadata` API as shown, and only inside run functions or task lifecycle hooks.
Applied to files:
apps/webapp/app/v3/services/createDeploymentBackgroundWorkerV4.server.tspackages/core/src/v3/schemas/resources.tsapps/webapp/app/v3/services/createDeploymentBackgroundWorkerV3.server.tspackages/core/src/v3/schemas/schemas.tspackages/core/src/v3/resource-catalog/catalog.tspackages/core/src/v3/resource-catalog/noopResourceCatalog.tspackages/core/src/v3/resource-catalog/index.tspackages/core/src/v3/types/tasks.tspackages/trigger-sdk/src/v3/shared.tspackages/core/src/v3/resource-catalog/standardResourceCatalog.tsapps/webapp/app/v3/services/createBackgroundWorker.server.ts
📚 Learning: applies to **/trigger/**/*.{ts,tsx,js,jsx} : you must use `@trigger.dev/sdk/v3` when writing trigger...
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : You MUST use `trigger.dev/sdk/v3` when writing Trigger.dev tasks.
Applied to files:
packages/trigger-sdk/package.jsonpackages/cli-v3/package.jsonpackages/trigger-sdk/src/v3/schemas.tspackages/trigger-sdk/src/v3/index.tspackages/schema-to-json/tsconfig.src.jsonpackages/schema-to-json/README.mdinternal-packages/database/prisma/schema.prismapackages/core/src/v3/types/tasks.tspackages/trigger-sdk/src/v3/shared.tspackages/cli-v3/src/entryPoints/dev-index-worker.tspackages/cli-v3/src/entryPoints/managed-index-worker.tspackages/schema-to-json/package.json
📚 Learning: applies to {packages/core,apps/webapp}/**/*.{ts,tsx} : we use zod a lot in packages/core and in the ...
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-07-18T17:49:24.468Z
Learning: Applies to {packages/core,apps/webapp}/**/*.{ts,tsx} : We use zod a lot in packages/core and in the webapp
Applied to files:
packages/trigger-sdk/package.jsonpackages/schema-to-json/tsconfig.jsonpackages/schema-to-json/tsconfig.test.jsonpackages/trigger-sdk/src/v3/index.tspackages/schema-to-json/README.mdpackages/schema-to-json/.gitignorepackages/schema-to-json/src/tests/index.test.ts
📚 Learning: applies to **/trigger/**/*.{ts,tsx,js,jsx} : always generate trigger.dev tasks using the `task` func...
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : ALWAYS generate Trigger.dev tasks using the `task` function from `trigger.dev/sdk/v3` and export them as shown in the correct pattern.
Applied to files:
packages/trigger-sdk/package.jsonpackages/core/src/v3/schemas/resources.tspackages/cli-v3/package.jsonpackages/trigger-sdk/src/v3/schemas.tspackages/core/src/v3/schemas/schemas.tspackages/schema-to-json/tsconfig.jsonpackages/core/src/v3/types/index.tspackages/core/src/v3/resource-catalog/catalog.tspackages/trigger-sdk/src/v3/index.tspackages/core/src/v3/resource-catalog/index.tspackages/schema-to-json/tsconfig.src.jsonpackages/schema-to-json/README.mdinternal-packages/database/prisma/schema.prismapackages/core/src/v3/types/tasks.tspackages/trigger-sdk/src/v3/shared.tspackages/core/src/v3/resource-catalog/standardResourceCatalog.tspackages/cli-v3/src/entryPoints/dev-index-worker.tspackages/schema-to-json/src/index.tspackages/cli-v3/src/entryPoints/managed-index-worker.tspackages/schema-to-json/package.json
📚 Learning: applies to **/trigger/**/*.{ts,tsx,js,jsx} : when implementing schema tasks, use `schematask` from `...
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : When implementing schema tasks, use `schemaTask` from `trigger.dev/sdk/v3` and validate payloads as shown.
Applied to files:
packages/trigger-sdk/package.jsonpackages/core/src/v3/schemas/resources.tspackages/cli-v3/package.jsonpackages/trigger-sdk/src/v3/schemas.tspackages/core/src/v3/schemas/schemas.tspackages/schema-to-json/tsconfig.jsonpackages/core/src/v3/types/index.tspackages/core/src/v3/resource-catalog/catalog.tspackages/core/src/v3/resource-catalog/noopResourceCatalog.tspackages/schema-to-json/tsconfig.test.jsonpackages/trigger-sdk/src/v3/index.tspackages/core/src/v3/resource-catalog/index.tspackages/schema-to-json/tsconfig.src.jsonpackages/schema-to-json/README.mdinternal-packages/database/prisma/schema.prismapackages/core/src/v3/types/tasks.tspackages/trigger-sdk/src/v3/shared.tspackages/core/src/v3/resource-catalog/standardResourceCatalog.tspackages/cli-v3/src/entryPoints/dev-index-worker.tspackages/schema-to-json/src/index.tspackages/cli-v3/src/entryPoints/managed-index-worker.tspackages/schema-to-json/src/tests/index.test.tsapps/webapp/app/v3/services/createBackgroundWorker.server.tspackages/core/src/v3/types/jsonSchema.tspackages/schema-to-json/package.json
📚 Learning: applies to trigger.config.ts : build extensions such as `additionalfiles`, `additionalpackages`, `ap...
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
Learning: Applies to trigger.config.ts : Build extensions such as `additionalFiles`, `additionalPackages`, `aptGet`, `emitDecoratorMetadata`, `prismaExtension`, `syncEnvVars`, `puppeteer`, `ffmpeg`, and `esbuildPlugin` must be configured in `trigger.config.ts` as shown.
Applied to files:
packages/trigger-sdk/package.jsonpackages/cli-v3/package.jsonpackages/trigger-sdk/src/v3/schemas.tspackages/schema-to-json/tsconfig.jsonpackages/schema-to-json/tsconfig.test.jsonpackages/trigger-sdk/src/v3/index.tspackages/schema-to-json/tsconfig.src.jsonpackages/schema-to-json/vitest.config.tspackages/schema-to-json/README.mdpackages/cli-v3/src/entryPoints/dev-index-worker.tspackages/cli-v3/src/entryPoints/managed-index-worker.tspackages/schema-to-json/package.json
📚 Learning: before generating any code for trigger.dev tasks, verify: (1) are you importing from `@trigger.dev/s...
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
Learning: Before generating any code for Trigger.dev tasks, verify: (1) Are you importing from `trigger.dev/sdk/v3`? (2) Have you exported every task? (3) Have you generated any deprecated code patterns?
Applied to files:
packages/trigger-sdk/package.jsonpackages/cli-v3/package.jsonpackages/trigger-sdk/src/v3/schemas.tspackages/trigger-sdk/src/v3/index.tspackages/schema-to-json/README.mdpackages/cli-v3/src/entryPoints/dev-index-worker.tspackages/cli-v3/src/entryPoints/managed-index-worker.tspackages/schema-to-json/package.json
📚 Learning: applies to trigger.config.ts : the `trigger.config.ts` file must use `defineconfig` from `@trigger.d...
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
Learning: Applies to trigger.config.ts : The `trigger.config.ts` file must use `defineConfig` from `trigger.dev/sdk/v3` and follow the configuration structure shown.
Applied to files:
packages/trigger-sdk/package.jsonpackages/cli-v3/package.jsonpackages/trigger-sdk/src/v3/schemas.tspackages/schema-to-json/tsconfig.jsonpackages/schema-to-json/tsconfig.test.jsonpackages/trigger-sdk/src/v3/index.tspackages/schema-to-json/tsconfig.src.jsonpackages/schema-to-json/vitest.config.tspackages/schema-to-json/README.mdpackages/cli-v3/src/entryPoints/dev-index-worker.tspackages/cli-v3/src/entryPoints/managed-index-worker.tspackages/schema-to-json/package.json
📚 Learning: applies to **/trigger/**/*.{ts,tsx,js,jsx} : never generate deprecated code patterns using `client.d...
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : NEVER generate deprecated code patterns using `client.defineJob` and related deprecated APIs, as shown in the prohibited code block.
Applied to files:
packages/trigger-sdk/package.jsonpackages/cli-v3/package.json
📚 Learning: applies to **/trigger/**/*.{ts,tsx,js,jsx} : when implementing scheduled (cron) tasks, use `schedule...
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : When implementing scheduled (cron) tasks, use `schedules.task` from `trigger.dev/sdk/v3` and follow the shown patterns.
Applied to files:
packages/trigger-sdk/package.jsonpackages/core/src/v3/schemas/resources.tspackages/cli-v3/package.jsonpackages/trigger-sdk/src/v3/schemas.tspackages/core/src/v3/schemas/schemas.tspackages/core/src/v3/resource-catalog/catalog.tsinternal-packages/database/prisma/schema.prismapackages/core/src/v3/types/tasks.tspackages/trigger-sdk/src/v3/shared.tspackages/cli-v3/src/entryPoints/dev-index-worker.tspackages/cli-v3/src/entryPoints/managed-index-worker.tspackages/schema-to-json/package.json
📚 Learning: applies to **/trigger/**/*.{ts,tsx,js,jsx} : if you are able to generate an example payload for a ta...
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : If you are able to generate an example payload for a task, do so.
Applied to files:
packages/core/src/v3/schemas/resources.tspackages/core/src/v3/schemas/schemas.tsinternal-packages/database/prisma/schema.prismapackages/core/src/v3/types/tasks.tspackages/trigger-sdk/src/v3/shared.tspackages/cli-v3/src/entryPoints/dev-index-worker.tspackages/cli-v3/src/entryPoints/managed-index-worker.ts
📚 Learning: applies to **/trigger/**/*.{ts,tsx,js,jsx} : when using retry, queue, machine, or maxduration option...
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : When using retry, queue, machine, or maxDuration options, configure them as shown in the examples for Trigger.dev tasks.
Applied to files:
packages/core/src/v3/schemas/resources.tspackages/cli-v3/package.jsonpackages/core/src/v3/schemas/schemas.tspackages/schema-to-json/tsconfig.src.jsoninternal-packages/database/prisma/schema.prismapackages/trigger-sdk/src/v3/shared.ts
📚 Learning: applies to **/trigger/**/*.{ts,tsx,js,jsx} : tasks must be exported, even subtasks in the same file....
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Tasks must be exported, even subtasks in the same file.
Applied to files:
packages/core/src/v3/schemas/resources.tspackages/trigger-sdk/src/v3/schemas.tspackages/core/src/v3/schemas/schemas.tspackages/schema-to-json/tsconfig.jsonpackages/core/src/v3/types/index.tspackages/core/src/v3/resource-catalog/catalog.tspackages/core/src/v3/resource-catalog/noopResourceCatalog.tspackages/trigger-sdk/src/v3/index.tspackages/schema-to-json/tsconfig.src.jsonpackages/core/src/v3/types/tasks.tspackages/trigger-sdk/src/v3/shared.tspackages/cli-v3/src/entryPoints/dev-index-worker.tspackages/cli-v3/src/entryPoints/managed-index-worker.tspackages/schema-to-json/package.json
📚 Learning: applies to **/trigger/**/*.{ts,tsx,js,jsx} : each task needs a unique id within your project....
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Each task needs a unique ID within your project.
Applied to files:
packages/core/src/v3/schemas/resources.tspackages/cli-v3/package.jsonpackages/core/src/v3/resource-catalog/noopResourceCatalog.tsinternal-packages/database/prisma/schema.prisma
📚 Learning: applies to **/trigger/**/*.{ts,tsx,js,jsx} : when triggering a task from backend code, use `tasks.tr...
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : When triggering a task from backend code, use `tasks.trigger`, `tasks.batchTrigger`, or `tasks.triggerAndPoll` as shown in the examples.
Applied to files:
packages/core/src/v3/schemas/resources.tspackages/core/src/v3/resource-catalog/catalog.tsinternal-packages/database/prisma/schema.prismapackages/core/src/v3/types/tasks.tspackages/trigger-sdk/src/v3/shared.tspackages/cli-v3/src/entryPoints/dev-index-worker.tspackages/cli-v3/src/entryPoints/managed-index-worker.ts
📚 Learning: applies to apps/webapp/**/*.{ts,tsx} : when importing from `@trigger.dev/core` in the webapp, never ...
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.180Z
Learning: Applies to apps/webapp/**/*.{ts,tsx} : When importing from `trigger.dev/core` in the webapp, never import from the root `trigger.dev/core` path; always use one of the subpath exports as defined in the package's package.json.
Applied to files:
packages/cli-v3/package.jsonpackages/trigger-sdk/src/v3/index.tspackages/schema-to-json/tsconfig.src.jsonpackages/cli-v3/src/entryPoints/dev-index-worker.tspackages/cli-v3/src/entryPoints/managed-index-worker.tspackages/schema-to-json/package.json
📚 Learning: applies to trigger.config.ts : global lifecycle hooks, telemetry, runtime, machine settings, log lev...
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
Learning: Applies to trigger.config.ts : Global lifecycle hooks, telemetry, runtime, machine settings, log level, max duration, and build configuration must be set in `trigger.config.ts` as shown.
Applied to files:
packages/cli-v3/package.jsonpackages/trigger-sdk/src/v3/schemas.tspackages/schema-to-json/tsconfig.src.jsonpackages/schema-to-json/vitest.config.tspackages/cli-v3/src/entryPoints/dev-index-worker.tspackages/cli-v3/src/entryPoints/managed-index-worker.ts
📚 Learning: applies to **/trigger/**/*.{ts,tsx,js,jsx} : you must `export` every task, including subtasks, in tr...
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : You MUST `export` every task, including subtasks, in Trigger.dev task files.
Applied to files:
packages/cli-v3/package.jsonpackages/trigger-sdk/src/v3/schemas.tspackages/core/src/v3/types/index.tspackages/core/src/v3/resource-catalog/catalog.tspackages/trigger-sdk/src/v3/index.tspackages/schema-to-json/tsconfig.src.jsonpackages/core/src/v3/types/tasks.tspackages/trigger-sdk/src/v3/shared.tspackages/cli-v3/src/entryPoints/dev-index-worker.tspackages/cli-v3/src/entryPoints/managed-index-worker.tspackages/schema-to-json/package.json
📚 Learning: applies to internal-packages/database/**/*.{ts,tsx} : we use prisma in internal-packages/database fo...
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-07-18T17:49:24.468Z
Learning: Applies to internal-packages/database/**/*.{ts,tsx} : We use prisma in internal-packages/database for our database interactions using PostgreSQL
Applied to files:
internal-packages/database/prisma/migrations/20250730084611_add_payload_schema_to_background_worker_task/migration.sqlpackages/schema-to-json/tsconfig.jsonpackages/schema-to-json/tsconfig.test.jsonpackages/trigger-sdk/src/v3/index.tspackages/schema-to-json/tsconfig.src.jsoninternal-packages/database/prisma/schema.prisma
📚 Learning: applies to **/tsconfig.json : use strict mode...
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-07-18T17:49:24.468Z
Learning: Applies to **/tsconfig.json : Use strict mode
Applied to files:
packages/schema-to-json/tsconfig.jsonpackages/schema-to-json/tsconfig.test.jsonpackages/schema-to-json/tsconfig.src.jsonpackages/schema-to-json/vitest.config.tspackages/cli-v3/src/entryPoints/dev-index-worker.tspackages/cli-v3/src/entryPoints/managed-index-worker.ts
📚 Learning: applies to **/*.{ts,tsx} : no default exports, use function declarations...
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-07-18T17:49:24.468Z
Learning: Applies to **/*.{ts,tsx} : No default exports, use function declarations
Applied to files:
packages/schema-to-json/tsconfig.jsonpackages/core/src/v3/types/index.tspackages/schema-to-json/tsconfig.test.jsonpackages/trigger-sdk/src/v3/index.tspackages/schema-to-json/tsconfig.src.jsonpackages/schema-to-json/vitest.config.tspackages/schema-to-json/src/index.ts
📚 Learning: applies to **/*.{ts,tsx} : for typescript, we usually use types over interfaces...
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-07-18T17:49:24.468Z
Learning: Applies to **/*.{ts,tsx} : For TypeScript, we usually use types over interfaces
Applied to files:
packages/schema-to-json/tsconfig.jsonpackages/schema-to-json/tsconfig.test.jsonpackages/core/src/v3/types/jsonSchema.ts
📚 Learning: applies to **/*.test.{ts,tsx} : our tests are all vitest...
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-07-18T17:49:24.468Z
Learning: Applies to **/*.test.{ts,tsx} : Our tests are all vitest
Applied to files:
packages/schema-to-json/tsconfig.jsonpackages/schema-to-json/tsconfig.test.jsonpackages/schema-to-json/vitest.config.tspackages/schema-to-json/.gitignorepackages/schema-to-json/src/tests/index.test.ts
📚 Learning: applies to apps/webapp/app/**/*.test.{ts,tsx} : tests in the webapp should only import classes and f...
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.180Z
Learning: Applies to apps/webapp/app/**/*.test.{ts,tsx} : Tests in the webapp should only import classes and functions from files matching `app/**/*.ts`, and those files should not use environment variables directly; all configuration should be passed as options.
Applied to files:
packages/schema-to-json/tsconfig.jsonpackages/core/src/v3/types/index.tspackages/schema-to-json/tsconfig.test.jsonpackages/trigger-sdk/src/v3/index.tspackages/schema-to-json/vitest.config.tspackages/schema-to-json/src/tests/index.test.ts
📚 Learning: applies to apps/webapp/**/*.{ts,tsx} : in the webapp, all environment variables must be accessed thr...
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.180Z
Learning: Applies to apps/webapp/**/*.{ts,tsx} : In the webapp, all environment variables must be accessed through the `env` export of `env.server.ts`, instead of directly accessing `process.env`.
Applied to files:
packages/core/src/v3/types/index.ts
📚 Learning: applies to apps/webapp/app/**/*.test.{ts,tsx} : test files in the webapp should not import `env.serv...
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.180Z
Learning: Applies to apps/webapp/app/**/*.test.{ts,tsx} : Test files in the webapp should not import `env.server.ts`, either directly or indirectly. Tests should only import classes and functions from files matching `app/**/*.ts` of the webapp, and those files should not use environment variables directly; everything should be passed through as options instead.
Applied to files:
packages/core/src/v3/types/index.tspackages/schema-to-json/tsconfig.test.jsonpackages/trigger-sdk/src/v3/index.tspackages/schema-to-json/vitest.config.tspackages/schema-to-json/src/tests/index.test.ts
📚 Learning: applies to **/trigger/**/*.{ts,tsx,js,jsx} : when triggering a task from inside another task, use `y...
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : When triggering a task from inside another task, use `yourTask.trigger`, `yourTask.batchTrigger`, `yourTask.triggerAndWait`, `yourTask.batchTriggerAndWait`, `batch.triggerAndWait`, `batch.triggerByTask`, or `batch.triggerByTaskAndWait` as shown.
Applied to files:
internal-packages/database/prisma/schema.prismapackages/trigger-sdk/src/v3/shared.ts
📚 Learning: applies to **/trigger/**/*.{ts,tsx,js,jsx} : you must never use `client.definejob` in trigger.dev ta...
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : You MUST NEVER use `client.defineJob` in Trigger.dev task files.
Applied to files:
internal-packages/database/prisma/schema.prisma
📚 Learning: applies to **/trigger/**/*.{ts,tsx,js,jsx} : the `run` function contains your task logic in trigger....
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : The `run` function contains your task logic in Trigger.dev tasks.
Applied to files:
packages/core/src/v3/types/tasks.ts
📚 Learning: follow our tests.md guide for how to write tests in the monorepo...
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tests.mdc:0-0
Timestamp: 2025-07-18T17:50:29.888Z
Learning: Follow our tests.md guide for how to write tests in the monorepo
Applied to files:
packages/schema-to-json/src/tests/index.test.ts
📚 Learning: in the docs.json configuration for the trigger.dev documentation (mintlify system), both "tags": ["v...
Learnt from: nicktrn
PR: triggerdotdev/trigger.dev#2155
File: docs/docs.json:179-183
Timestamp: 2025-06-06T16:54:23.316Z
Learning: In the docs.json configuration for the Trigger.dev documentation (Mintlify system), both "tags": ["v4"] and "tag": "v4" properties can be used together and work correctly, even though this behavior is undocumented and may not work in local development environments.
Applied to files:
packages/schema-to-json/package.json
🧬 Code Graph Analysis (7)
packages/core/src/v3/resource-catalog/catalog.ts (1)
packages/core/src/v3/types/tasks.ts (1)
TaskSchema(34-34)
packages/core/src/v3/resource-catalog/noopResourceCatalog.ts (1)
packages/core/src/v3/types/tasks.ts (1)
TaskSchema(34-34)
packages/core/src/v3/resource-catalog/index.ts (1)
packages/core/src/v3/types/tasks.ts (1)
TaskSchema(34-34)
packages/core/src/v3/types/tasks.ts (1)
packages/core/src/v3/types/jsonSchema.ts (1)
JSONSchema(5-67)
packages/trigger-sdk/src/v3/shared.ts (1)
packages/core/src/v3/types/tasks.ts (4)
InitOutput(86-86)TaskOptionsWithSchema(359-365)Task(542-621)TaskOptions(351-356)
packages/cli-v3/src/entryPoints/dev-index-worker.ts (3)
packages/core/src/v3/resource-catalog-api.ts (1)
resourceCatalog(5-5)packages/core/src/v3/schemas/schemas.ts (2)
TaskManifest(216-219)TaskManifest(221-221)packages/schema-to-json/src/index.ts (2)
initializeSchemaConverters(179-209)schemaToJsonSchema(50-172)
packages/schema-to-json/src/tests/index.test.ts (1)
packages/schema-to-json/src/index.ts (5)
initializeSchemaConverters(179-209)areConvertersInitialized(230-243)schemaToJsonSchema(50-172)canConvertSchema(214-217)detectSchemaType(222-225)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (23)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (6, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (8, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (7, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (3, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (5, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (4, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (2, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (1, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (2, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (5, 8)
- GitHub Check: units / packages / 🧪 Unit Tests: Packages (1, 1)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (1, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (3, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (8, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (4, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (6, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (7, 8)
- GitHub Check: e2e / 🧪 CLI v3 tests (ubuntu-latest - pnpm)
- GitHub Check: e2e / 🧪 CLI v3 tests (ubuntu-latest - npm)
- GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - npm)
- GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - pnpm)
- GitHub Check: typecheck / typecheck
- GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (35)
packages/trigger-sdk/package.json (1)
75-82: Peer range widened but dev-dependency still pinned to3.x
peerDependencies.zodnow allows^4.0.0, yet the localdevDependencies.zodremains fixed at3.23.8.
If we publish with this range, consumers on Zod 4 may compile against types the SDK itself has never been built or tested with, risking breaking changes.Consider one of:
- "zod": "3.23.8" + "zod": "^3.23.8 || ^4.0.0" // keep in sync with peer rangeor bump CI to build against Zod 4 prior to widening the peer spec.
Otherwise tighten the peer spec back to^3.0.0until full Zod 4 support is confirmed.
[tagged versions mismatch]packages/trigger-sdk/src/v3/index.ts (1)
17-18: Export added – verify build path exists
export * from "./schemas.js";assumes thatsrc/v3/schemas.ts(→schemas.jsafter build) is present in the same package entry graph.
Please confirm the file is included infiles/tshy.exportsso it lands in the published tarball; missing files break consumers at runtime.packages/schema-to-json/.gitignore (1)
1-6: LGTM – standard ignores.
Nothing out of the ordinary; matches the conventions used in sibling packages.packages/trigger-sdk/src/v3/schemas.ts (1)
1-2: Re-export looks good.Small utility file, no functional concerns. Thanks for avoiding a default export per guidelines.
packages/core/src/v3/schemas/schemas.ts (1)
192-193: Leverage the strongly-typedJSONSchemainstead ofz.unknown()
payloadSchemais expected to contain a Draft-7 JSON Schema. Declaring it asz.unknown()forfeits type-safety and autocomplete across the codebase.-import { z } from "zod"; +import { z } from "zod"; +import type { JSONSchema } from "../types/jsonSchema.js"; // <-- already added in this PR … - payloadSchema: z.unknown().optional(), + // Accept any valid JSON-Schema draft-7 object at runtime while still providing compile-time guarantees. + payloadSchema: z.custom<JSONSchema>().optional(),The
customwrapper keeps runtime validation permissive (no extra cost) but gives every downstream consumer the correct type instead ofunknown.This change ripples automatically to
TaskManifest,TaskFileManifest, etc., because they spreadtaskMetadata.
[ suggest_essential_refactor ]packages/core/src/v3/schemas/resources.ts (1)
16-18: Mirror the stronger typing forpayloadSchemahere as wellAfter tightening the type in
schemas.ts, do the same inresources.tsto keep the two source-of-truth schemas consistent:-import { z } from "zod"; +import { z } from "zod"; +import type { JSONSchema } from "../types/jsonSchema.js"; … - payloadSchema: z.unknown().optional(), + payloadSchema: z.custom<JSONSchema>().optional(),Avoiding the
unknownsurface area makes IntelliSense and refactors safer when other packages (SDK, CLI) consumeTaskResource.
[ suggest_essential_refactor ]packages/schema-to-json/tsconfig.json (1)
1-11: Verify thatstrictcompiler options stay enabledThis file delegates to
../../.configs/tsconfig.base.json, so strict mode depends on that parent. Double-check the base config still contains"strict": true; otherwise add an override here:"extends": "../../.configs/tsconfig.base.json", + "compilerOptions": { + "strict": true + },Ensuring strictness for the new package prevents silent
anys while dealing with heterogeneous schema libraries.
[ request_verification ]packages/schema-to-json/tsconfig.test.json (1)
5-10: Consider keepingisolatedDeclarationsenabledDisabling
isolatedDeclarationsmakes the test project incompatible withtsc -bincremental builds and may hide circular-reference issues. Unless you hit a concrete.d.tsgeneration problem, drop the override:- "isolatedDeclarations": false,If declaration files truly aren’t needed for tests, you can keep
isolatedDeclarationson while adding"declaration": falseinstead.
[ suggest_optional_refactor ]packages/schema-to-json/vitest.config.ts (1)
3-8: Exception to “no default export” guideline is acceptable here
vitestlooks specifically for a default export, so keepingexport default defineConfig(...)is the correct choice even though the repo guideline discourages default exports for application code. No action required.
[ approve_code_changes ]packages/core/src/v3/types/index.ts (1)
10-10: LGTM! Clean addition to the public API.The new export for
./jsonSchema.jsfollows the existing pattern and properly extends the public API to support the JSON Schema functionality introduced in this PR.packages/core/src/v3/resource-catalog/index.ts (2)
4-4: LGTM! Proper import addition.The import of
TaskSchemais necessary for the newgetTaskSchemamethod and follows the existing import pattern.
68-70: LGTM! Consistent API extension.The
getTaskSchemamethod follows the established delegation pattern and maintains consistency with other getter methods in the class. The return type properly handles the possibility of a missing schema withundefined.packages/core/src/v3/resource-catalog/noopResourceCatalog.ts (2)
2-2: LGTM! Necessary import for the new method.The import of
TaskSchemais required for the newgetTaskSchemamethod signature and follows the existing import pattern.
34-36: LGTM! Appropriate no-op implementation.The
getTaskSchemamethod correctly returnsundefinedas expected for a no-op implementation, maintaining consistency with other no-op methods likegetTaskManifestandgetTask.packages/core/src/v3/resource-catalog/catalog.ts (2)
2-2: LGTM! Required import for the interface method.The import of
TaskSchemais necessary for the new interface method and follows the existing import pattern.
16-16: LGTM! Clean interface extension.The
getTaskSchemamethod signature follows the established pattern of other getter methods in the interface, with consistent parameter naming and appropriate return type handling for missing schemas.packages/cli-v3/src/entryPoints/dev-index-worker.ts (2)
21-21: Import looks good.The import statement correctly brings in the necessary schema conversion utilities from the new
@trigger.dev/schema-to-jsonpackage.
104-104: Correct integration of schema conversion.The replacement of the direct task listing with the awaited conversion function properly integrates JSON schema support into the task indexing flow.
packages/cli-v3/src/entryPoints/managed-index-worker.ts (2)
21-21: Import consistency maintained.Good to see consistent imports between dev and managed workers.
104-104: Proper integration of schema conversion.The schema conversion is correctly integrated into the managed worker flow.
packages/core/src/v3/types/tasks.ts (4)
31-31: Correct import of JSONSchema type.The import properly brings in the JSONSchema interface for type safety.
344-348: Good addition of JSON schema support.The optional
jsonSchemaproperty inCommonTaskOptionsprovides a clean way to specify JSON Schema validation for task payloads. The JSDoc comment clearly explains the purpose and format requirements.
358-365: Well-designed type alias for schema-based tasks.
TaskOptionsWithSchemacorrectly requires thejsonSchemaproperty while usinganyfor the payload type, which makes sense since the actual payload validation happens at runtime through the schema.
900-900: Consistent schema property addition.The optional
schemaproperty inTaskMetadataWithFunctionsfollows the established naming pattern and properly uses theTaskSchematype.packages/core/src/v3/resource-catalog/standardResourceCatalog.ts (5)
8-8: Correct imports for schema support.The import properly brings in the required types for task schema functionality.
12-12: Proper schema storage initialization.The private
_taskSchemasMap is correctly typed and initialized, following the established pattern for other metadata storage in the class.
77-79: Safe schema registration logic.The conditional schema storage only registers schemas when they exist, preventing unnecessary entries in the Map.
115-120: Minor refactoring improves readability.The assignment of the combined metadata to a local variable before pushing to the result array improves code clarity without changing the behavior.
126-128: Clean schema retrieval interface.The
getTaskSchemamethod provides a simple, consistent interface for retrieving task schemas, following the same pattern as other getter methods in the class.packages/core/src/v3/types/jsonSchema.ts (2)
1-4: Good documentation and context.The comment clearly explains the purpose and compatibility of the JSON Schema definition.
69-76: Complete and accurate JSONSchemaType definition.The union type correctly covers all valid JSON Schema primitive types as defined in the JSON Schema specification.
packages/schema-to-json/README.md (1)
1-151: Well-documented package with clear usage examples!The README provides comprehensive documentation including installation instructions, bundle safety considerations, supported libraries, API reference, and practical usage examples. The explanation of built-in vs external conversions is particularly helpful for users to understand the package's design philosophy.
packages/schema-to-json/src/tests/index.test.ts (1)
1-351: Excellent test coverage!The test suite comprehensively covers all supported schema libraries with both basic and edge cases. The organization by schema type and functionality makes the tests easy to understand and maintain. Good job including tests for initialization, conversion, detection, and error handling.
packages/trigger-sdk/src/v3/shared.ts (2)
132-160: Well-implemented function overloads for schema support!The overloads correctly handle both schema-based and regular tasks, with appropriate type constraints. The implementation properly sets the
payloadSchemafield when a JSON schema is provided, maintaining backward compatibility while adding new functionality.Also applies to: 229-229
364-364: Consistent schema handling in createSchemaTask.The schema property is correctly set in the resource catalog metadata, complementing the JSON schema support added to createTask.
apps/webapp/app/v3/services/createDeploymentBackgroundWorkerV3.server.ts
Outdated
Show resolved
Hide resolved
apps/webapp/app/v3/services/createDeploymentBackgroundWorkerV4.server.ts
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (4)
packages/schema-to-json/tests/index.test.ts (4)
86-113: Enhance Zod 4 mock schema test.The mock schema test is good but could benefit from more realistic implementation to better represent actual Zod 4 behavior.
Consider enhancing the mock to be more representative:
const mockZod4Schema = { + _def: { typeName: "ZodObject" }, // More realistic Zod structure parse: (val: unknown) => val, parseAsync: async (val: unknown) => val, + safeParse: (val: unknown) => ({ success: true, data: val }), toJsonSchema: () => ({ type: "object", properties: { id: { type: "string" }, count: { type: "number" }, }, required: ["id", "count"], }), };
161-175: ArkType test needs more specific assertions.The ArkType test only checks basic properties. Consider adding more specific assertions about the schema structure.
expect(result?.jsonSchema).toBeDefined(); expect(result?.jsonSchema.type).toBe("object"); + expect(result?.jsonSchema.properties).toBeDefined(); + expect(result?.jsonSchema.properties?.name?.type).toBe("string"); + expect(result?.jsonSchema.properties?.age?.type).toBe("number"); + expect(result?.jsonSchema.properties?.active?.type).toBe("boolean");
215-227: Effect schema test needs more specific assertions.Similar to ArkType, the Effect schema optional fields test only checks basic properties.
expect(result?.jsonSchema).toBeDefined(); expect(result?.jsonSchema.type).toBe("object"); + expect(result?.jsonSchema.properties?.id).toBeDefined(); + expect(result?.jsonSchema.properties?.description).toBeDefined(); + expect(result?.jsonSchema.properties?.count).toBeDefined(); + // Verify required fields + expect(result?.jsonSchema.required).toEqual(["id"]);
1-350: Consider adding error handling and performance tests.The test suite is comprehensive but could benefit from additional test categories:
- Error handling tests for malformed schemas
- Performance tests for large schema conversion
- Tests for edge cases like circular references
- Tests for nested complex schemas
Consider adding these test cases:
describe("Error handling", () => { it("should handle malformed Zod schemas gracefully", () => { const malformedSchema = { _def: null }; expect(() => schemaToJsonSchema(malformedSchema)).not.toThrow(); }); }); describe("Complex schemas", () => { it("should handle deeply nested schemas", () => { const schema = z.object({ user: z.object({ profile: z.object({ settings: z.object({ theme: z.string(), }), }), }), }); const result = schemaToJsonSchema(schema); expect(result?.jsonSchema).toBeDefined(); }); });
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
references/hello-world/src/trigger/example.tsis excluded by!references/**
📒 Files selected for processing (7)
packages/cli-v3/src/entryPoints/dev-index-worker.ts(3 hunks)packages/cli-v3/src/entryPoints/managed-index-worker.ts(3 hunks)packages/schema-to-json/package.json(1 hunks)packages/schema-to-json/src/index.ts(1 hunks)packages/schema-to-json/tests/index.test.ts(1 hunks)packages/schema-to-json/tsconfig.src.json(1 hunks)packages/schema-to-json/tsconfig.test.json(1 hunks)
✅ Files skipped from review due to trivial changes (1)
- packages/schema-to-json/package.json
🚧 Files skipped from review as they are similar to previous changes (5)
- packages/schema-to-json/tsconfig.test.json
- packages/schema-to-json/tsconfig.src.json
- packages/cli-v3/src/entryPoints/dev-index-worker.ts
- packages/cli-v3/src/entryPoints/managed-index-worker.ts
- packages/schema-to-json/src/index.ts
🧰 Additional context used
📓 Path-based instructions (2)
**/*.{ts,tsx}
📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)
**/*.{ts,tsx}: Always prefer using isomorphic code like fetch, ReadableStream, etc. instead of Node.js specific code
For TypeScript, we usually use types over interfaces
Avoid enums
No default exports, use function declarations
Files:
packages/schema-to-json/tests/index.test.ts
**/*.test.{ts,tsx}
📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)
Our tests are all vitest
Files:
packages/schema-to-json/tests/index.test.ts
🧠 Learnings (6)
📓 Common learnings
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : When implementing schema tasks, use `schemaTask` from `trigger.dev/sdk/v3` and validate payloads as shown.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : If you are able to generate an example payload for a task, do so.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : ALWAYS generate Trigger.dev tasks using the `task` function from `trigger.dev/sdk/v3` and export them as shown in the correct pattern.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : When implementing scheduled (cron) tasks, use `schedules.task` from `trigger.dev/sdk/v3` and follow the shown patterns.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : When triggering a task from backend code, use `tasks.trigger`, `tasks.batchTrigger`, or `tasks.triggerAndPoll` as shown in the examples.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
Learning: Before generating any code for Trigger.dev tasks, verify: (1) Are you importing from `trigger.dev/sdk/v3`? (2) Have you exported every task? (3) Have you generated any deprecated code patterns?
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : You MUST use `trigger.dev/sdk/v3` when writing Trigger.dev tasks.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Each task needs a unique ID within your project.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
Learning: Applies to trigger.config.ts : Build extensions such as `additionalFiles`, `additionalPackages`, `aptGet`, `emitDecoratorMetadata`, `prismaExtension`, `syncEnvVars`, `puppeteer`, `ffmpeg`, and `esbuildPlugin` must be configured in `trigger.config.ts` as shown.
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-07-18T17:49:24.468Z
Learning: Applies to internal-packages/database/**/*.{ts,tsx} : We use prisma in internal-packages/database for our database interactions using PostgreSQL
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : Tasks must be exported, even subtasks in the same file.
📚 Learning: applies to **/*.test.{ts,tsx} : our tests are all vitest...
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-07-18T17:49:24.468Z
Learning: Applies to **/*.test.{ts,tsx} : Our tests are all vitest
Applied to files:
packages/schema-to-json/tests/index.test.ts
📚 Learning: applies to apps/webapp/app/**/*.test.{ts,tsx} : tests in the webapp should only import classes and f...
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.180Z
Learning: Applies to apps/webapp/app/**/*.test.{ts,tsx} : Tests in the webapp should only import classes and functions from files matching `app/**/*.ts`, and those files should not use environment variables directly; all configuration should be passed as options.
Applied to files:
packages/schema-to-json/tests/index.test.ts
📚 Learning: follow our tests.md guide for how to write tests in the monorepo...
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tests.mdc:0-0
Timestamp: 2025-07-18T17:50:29.888Z
Learning: Follow our tests.md guide for how to write tests in the monorepo
Applied to files:
packages/schema-to-json/tests/index.test.ts
📚 Learning: applies to **/trigger/**/*.{ts,tsx,js,jsx} : when implementing schema tasks, use `schematask` from `...
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/writing-tasks.mdc:0-0
Timestamp: 2025-07-18T17:50:25.014Z
Learning: Applies to **/trigger/**/*.{ts,tsx,js,jsx} : When implementing schema tasks, use `schemaTask` from `trigger.dev/sdk/v3` and validate payloads as shown.
Applied to files:
packages/schema-to-json/tests/index.test.ts
📚 Learning: applies to apps/webapp/app/**/*.test.{ts,tsx} : test files in the webapp should not import `env.serv...
Learnt from: CR
PR: triggerdotdev/trigger.dev#0
File: .cursor/rules/webapp.mdc:0-0
Timestamp: 2025-07-18T17:49:47.180Z
Learning: Applies to apps/webapp/app/**/*.test.{ts,tsx} : Test files in the webapp should not import `env.server.ts`, either directly or indirectly. Tests should only import classes and functions from files matching `app/**/*.ts` of the webapp, and those files should not use environment variables directly; everything should be passed through as options instead.
Applied to files:
packages/schema-to-json/tests/index.test.ts
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (23)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (2, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (5, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (4, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (8, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (8, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (6, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (3, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (6, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (7, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (1, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (5, 8)
- GitHub Check: units / internal / 🧪 Unit Tests: Internal (1, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (7, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (4, 8)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (2, 8)
- GitHub Check: units / packages / 🧪 Unit Tests: Packages (1, 1)
- GitHub Check: units / webapp / 🧪 Unit Tests: Webapp (3, 8)
- GitHub Check: e2e / 🧪 CLI v3 tests (ubuntu-latest - pnpm)
- GitHub Check: typecheck / typecheck
- GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - npm)
- GitHub Check: e2e / 🧪 CLI v3 tests (windows-latest - pnpm)
- GitHub Check: e2e / 🧪 CLI v3 tests (ubuntu-latest - npm)
- GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (7)
packages/schema-to-json/tests/index.test.ts (7)
15-18: LGTM - Proper test initialization.The
beforeAllhook correctly initializes schema converters before running tests, which is essential for the dynamic loading functionality.
21-28: LGTM - Initialization verification tests.Good practice to verify that converters are properly initialized before testing conversion functionality.
31-51: LGTM - Comprehensive Zod schema test.The test covers a well-structured object schema with different field types and properly validates the converted JSON Schema structure.
275-294: LGTM - Good test for additional properties feature.The test properly validates that additional properties are merged into the resulting JSON Schema.
296-308: LGTM - Proper edge case handling.Good coverage of unsupported schema types and edge cases.
311-324: LGTM - Comprehensive utility function tests.The
canConvertSchematests cover both positive and negative cases effectively.
326-350: LGTM - Complete schema type detection tests.The
detectSchemaTypetests cover all supported schema types and the unknown case.
Overview
This PR introduces JSON Schema indexing for
taskandschemaTask. Withtask, users can now pass ajsonSchemaoption. ForschemaTask, we will automatically convert the payload schema to a json schema if we can. Currently this is only used during indexing and not runtime validation, which will come in a later update.Technical Implementation
Core Architecture
We've introduced a new
payloadSchemaattribute on tasks that accepts JSON Schema Draft 7 definitions:Multi-Library Support
Through our new
@trigger.dev/schema-to-jsonpackage, we support automatic conversion from popular validation libraries.Implementation Details
Database Schema Evolution
Added
payloadSchemacolumn to theBackgroundWorkerTasktable to persist JSON Schema definitions:Bundle Safety
The
@trigger.dev/schema-to-jsonpackage uses dynamic imports to ensure schema conversion libraries are only loaded when needed:Type Safety
Introduced proper TypeScript types for JSON Schema Draft 7:
Future Enhancements
This foundation enables several planned features:
Breaking Changes
None. This feature is fully backwards compatible. Existing tasks without
jsonSchemacontinue to work as before.