Expose authoritative watch inputs from contract configs#356
Expose authoritative watch inputs from contract configs#356
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughThe PR refactors the contract source provider API from a directly-callable async function to a structured object with Changes
Sequence Diagram(s)sequenceDiagram
participant CLI as CLI/Vite Plugin
participant ConfigLoader as Config Loader
participant Validator as Validator
participant Provider as Contract Source Provider
participant FS as File System
CLI->>ConfigLoader: loadConfig(configPath)
ConfigLoader->>ConfigLoader: resolve config path + load via c12
ConfigLoader->>Validator: validateConfig(config)
Validator->>Validator: validate contract.source.load (function)
Validator->>Validator: validate contract.source.inputs (array)
Validator->>Validator: validate no inputs match output artifacts
Validator-->>ConfigLoader: validated config
ConfigLoader-->>CLI: PrismaNextConfig
CLI->>CLI: resolveWatchedFiles()
CLI->>CLI: collect config path + contract.source.inputs
CLI->>CLI: build module graph from config + input paths
CLI->>CLI: filter out contract output artifacts
CLI-->>CLI: watched file set
CLI->>Provider: source.load(context, { configDir })
FS->>Provider: resolve contractPath relative to configDir
Provider->>FS: read/parse schema or import module
Provider-->>CLI: Result<Contract, Diagnostics>
CLI->>CLI: emit contract + update watched files
FS-->>CLI: file system watches for changes
CLI->>CLI: handleTrackedFileChange(file)
alt file in ignoredOutputFiles
CLI-->>CLI: ignore (self-triggered)
else file in watchedFiles
CLI->>Provider: source.load(...) again
Provider-->>CLI: Result<Contract>
CLI->>CLI: emit contract
end
Estimated code review effort🎯 4 (Complex) | ⏱️ ~75 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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. Comment |
@prisma-next/mongo-runtime
@prisma-next/family-mongo
@prisma-next/sql-runtime
@prisma-next/family-sql
@prisma-next/middleware-telemetry
@prisma-next/mongo
@prisma-next/extension-paradedb
@prisma-next/extension-pgvector
@prisma-next/postgres
@prisma-next/sql-orm-client
@prisma-next/sqlite
@prisma-next/target-mongo
@prisma-next/adapter-mongo
@prisma-next/driver-mongo
@prisma-next/contract
@prisma-next/utils
@prisma-next/config
@prisma-next/errors
@prisma-next/framework-components
@prisma-next/operations
@prisma-next/contract-authoring
@prisma-next/ids
@prisma-next/psl-parser
@prisma-next/psl-printer
@prisma-next/cli
@prisma-next/emitter
@prisma-next/migration-tools
prisma-next
@prisma-next/vite-plugin-contract-emit
@prisma-next/runtime-executor
@prisma-next/mongo-codec
@prisma-next/mongo-contract
@prisma-next/mongo-value
@prisma-next/mongo-contract-psl
@prisma-next/mongo-contract-ts
@prisma-next/mongo-emitter
@prisma-next/mongo-schema-ir
@prisma-next/mongo-query-ast
@prisma-next/mongo-orm
@prisma-next/mongo-pipeline-builder
@prisma-next/mongo-lowering
@prisma-next/mongo-wire
@prisma-next/sql-contract
@prisma-next/sql-errors
@prisma-next/sql-operations
@prisma-next/sql-schema-ir
@prisma-next/sql-contract-psl
@prisma-next/sql-contract-ts
@prisma-next/sql-contract-emitter
@prisma-next/sql-lane-query-builder
@prisma-next/sql-relational-core
@prisma-next/sql-builder
@prisma-next/target-postgres
@prisma-next/target-sqlite
@prisma-next/adapter-postgres
@prisma-next/adapter-sqlite
@prisma-next/driver-postgres
@prisma-next/driver-sqlite
commit: |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (2)
packages/1-framework/3-tooling/cli/test/config-loader.test.ts (1)
68-167: Good coverage of the new metadata paths.The four new cases exercise the authoritative-inputs,
moduleGraph, default-artifact filtering, and fallback-warning branches. Use oftoEqualon the fullcontractWatchobject is aligned with the "prefer object matchers" guideline.One small suggestion: the last case uses
result.metadata.contractWatch?.inputswith optional chaining; sincecontractis present in the config,contractWatchis guaranteed non-null — prefer a non-null assertion or assert on the full object viatoEqual/toMatchObjectto keep style consistent with the other three cases.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/1-framework/3-tooling/cli/test/config-loader.test.ts` around lines 68 - 167, The test uses optional chaining when asserting contract watch metadata (result.metadata.contractWatch?.inputs) but contract is always present here; replace the optional assertion with a non-null assertion or assert the entire object like the other tests (e.g., expect(result.metadata.contractWatch).toEqual(...) or toMatchObject(...)) so the style is consistent with the other cases and avoids the unnecessary optional chaining (refer to result.metadata.contractWatch and the surrounding it block).packages/1-framework/3-tooling/cli/src/config-loader.ts (1)
47-50: Unnecessary optional chaining onoutputJsonPath.
resolve(...)always returns a non-nullable string, sooutputJsonPath?.endsWith('.json')can be simplified tooutputJsonPath.endsWith('.json').Proposed nit
- const outputDtsPath = outputJsonPath?.endsWith('.json') + const outputDtsPath = outputJsonPath.endsWith('.json') ? `${outputJsonPath.slice(0, -5)}.d.ts` : undefined;Also worth noting: when
contract.outputuses a non-.jsonextension, the colocated.d.tsartifact won't be filtered out ofwatchInputs. That's probably fine given the canonical output is.json, but worth a comment if that's intentional.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/1-framework/3-tooling/cli/src/config-loader.ts` around lines 47 - 50, The optional chaining on outputJsonPath is unnecessary because resolve(...) always returns a string; update the conditional that sets outputDtsPath to use outputJsonPath.endsWith('.json') instead of outputJsonPath?.endsWith('.json') and remove the redundant null-safety. Locate the code that computes outputJsonPath (uses resolve(configDir, contract.output ?? DEFAULT_CONTRACT_OUTPUT)) and outputDtsPath and make the change; optionally add a brief comment near outputDtsPath noting that non-".json" contract.output values will not produce a colocated ".d.ts" (so watchInputs may include it) if you want to document that behavior.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@packages/1-framework/3-tooling/cli/src/config-loader.ts`:
- Around line 47-50: The optional chaining on outputJsonPath is unnecessary
because resolve(...) always returns a string; update the conditional that sets
outputDtsPath to use outputJsonPath.endsWith('.json') instead of
outputJsonPath?.endsWith('.json') and remove the redundant null-safety. Locate
the code that computes outputJsonPath (uses resolve(configDir, contract.output
?? DEFAULT_CONTRACT_OUTPUT)) and outputDtsPath and make the change; optionally
add a brief comment near outputDtsPath noting that non-".json" contract.output
values will not produce a colocated ".d.ts" (so watchInputs may include it) if
you want to document that behavior.
In `@packages/1-framework/3-tooling/cli/test/config-loader.test.ts`:
- Around line 68-167: The test uses optional chaining when asserting contract
watch metadata (result.metadata.contractWatch?.inputs) but contract is always
present here; replace the optional assertion with a non-null assertion or assert
the entire object like the other tests (e.g.,
expect(result.metadata.contractWatch).toEqual(...) or toMatchObject(...)) so the
style is consistent with the other cases and avoids the unnecessary optional
chaining (refer to result.metadata.contractWatch and the surrounding it block).
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yml
Review profile: CHILL
Plan: Pro
Run ID: 75bf42d9-cb80-4ee9-b957-e1dbac73ee33
📒 Files selected for processing (20)
packages/1-framework/1-core/config/README.mdpackages/1-framework/1-core/config/src/config-types.tspackages/1-framework/1-core/config/src/config-validation.tspackages/1-framework/1-core/config/test/config-types.test-d.tspackages/1-framework/1-core/config/test/config-validation.test.tspackages/1-framework/3-tooling/cli/src/config-loader.tspackages/1-framework/3-tooling/cli/test/config-loader.test.tspackages/1-framework/3-tooling/cli/test/config-types.test.tspackages/2-mongo-family/2-authoring/contract-psl/src/provider.tspackages/2-mongo-family/2-authoring/contract-psl/test/provider.test.tspackages/2-mongo-family/2-authoring/contract-ts/src/config-types.tspackages/2-mongo-family/2-authoring/contract-ts/test/config-types.test.tspackages/2-sql/2-authoring/contract-psl/src/provider.tspackages/2-sql/2-authoring/contract-psl/test/provider.test.tspackages/2-sql/2-authoring/contract-ts/src/config-types.tspackages/2-sql/2-authoring/contract-ts/test/config-types.test.tspackages/3-extensions/mongo/src/config/define-config.tspackages/3-extensions/mongo/test/config/define-config.test.tspackages/3-extensions/postgres/src/config/define-config.tspackages/3-extensions/postgres/test/config/define-config.test.ts
There was a problem hiding this comment.
I like the direction to make a ContractSourceProvider explicitly return its sources. I don't think the framework should be aware of dev watcher integrations though. Also watchStrategy appears to have no consumer and it's unclear from its doc comment what its future purpose will be. In any case, this doesn't belong in Prisma Next config, it belongs in the watcher integration's config
So I recommend:
- rename the watcher-coupled properties of the contractProvider to be consumer agnostic, eg
watcherInputscould as easily besourcesorsourceFilesetc - move watcher-specific config (
watcherStrategy) to the watcher integration (ie the vite or NextJS integratio)
|
I agree with this review. The current change solves the Vite invalidation problem, but it does it at the wrong boundary: it teaches I think the cleaner model is:
So instead of
That also addresses the “why is this optional?” point. Every provider should declare its authoritative source model explicitly. For built-ins, that means:
Then the Vite plugin can resolve that provider metadata into watched files, filter out emitted artifacts, and handle the partial-coverage warning there. That keeps the fallback behavior we want for custom providers, but avoids encoding it as implicit back-compat logic in the generic config loader. I'll get rid of the retro-compatibility that snuck in. Separately, if any validation remains for this shape, it should live in the Arktype schema rather than in ad hoc manual checks. |
There was a problem hiding this comment.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
test/integration/test/cli.emit-command.test.ts (1)
568-570:⚠️ Potential issue | 🟡 MinorStale type annotation for
sourceResult.
typeof providerConfig.contract['source']is now an object (withauthoritativeInputs+load), not a callable, soReturnType<...>on it is invalid. The annotation happens to still resolve (likely tonever/broken inference) but no longer describes the load result. UseReturnType<NonNullable<typeof providerConfig.contract>['source']['load']>instead.Proposed fix
- let sourceResult: Awaited< - ReturnType<NonNullable<typeof providerConfig.contract>['source']> - >; + let sourceResult: Awaited< + ReturnType<NonNullable<typeof providerConfig.contract>['source']['load']> + >;🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test/integration/test/cli.emit-command.test.ts` around lines 568 - 570, The type annotation for sourceResult is stale because providerConfig.contract['source'] is now an object with a load method; update the declaration to use the load method's return type by replacing ReturnType<NonNullable<typeof providerConfig.contract>['source']> with ReturnType<NonNullable<typeof providerConfig.contract>['source']['load']> (keep the NonNullable wrapper) so sourceResult correctly reflects the load result from providerConfig.contract.source.load.test/integration/test/authoring/cli.emit-parity-fixtures.test.ts (1)
95-98:⚠️ Potential issue | 🟡 MinorUpdate
ReturnType<typeof …source>annotations to target.source.load.Same issue as in
cli.emit-command.test.ts:contract.sourceis now an object, not a function, soReturnType<typeof tsConfig.contract.source>(and the matching psl/diagnostics ones) no longer reflects theload()result type. Point these at.source.loadinstead.Proposed fix
- let tsProviderResultFirst: Awaited<ReturnType<typeof tsConfig.contract.source>>; - let tsProviderResultSecond: Awaited<ReturnType<typeof tsConfig.contract.source>>; - let pslProviderResultFirst: Awaited<ReturnType<typeof pslConfig.contract.source>>; - let pslProviderResultSecond: Awaited<ReturnType<typeof pslConfig.contract.source>>; + let tsProviderResultFirst: Awaited<ReturnType<typeof tsConfig.contract.source.load>>; + let tsProviderResultSecond: Awaited<ReturnType<typeof tsConfig.contract.source.load>>; + let pslProviderResultFirst: Awaited<ReturnType<typeof pslConfig.contract.source.load>>; + let pslProviderResultSecond: Awaited<ReturnType<typeof pslConfig.contract.source.load>>; ... - let sourceResult: Awaited<ReturnType<typeof pslConfig.contract.source>>; + let sourceResult: Awaited<ReturnType<typeof pslConfig.contract.source.load>>;Also applies to: 241-241
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test/integration/test/authoring/cli.emit-parity-fixtures.test.ts` around lines 95 - 98, The type aliases for provider result variables use ReturnType<typeof ...contract.source> but contract.source is now an object; change the annotations to target the load method return type instead (e.g., use Awaited<ReturnType<typeof tsConfig.contract.source.load>> for tsProviderResultFirst/Second and similarly use Awaited<ReturnType<typeof pslConfig.contract.source.load>> for pslProviderResultFirst/Second and update any diagnostics-related ReturnType references to point at .source.load as well) so the types reflect the result of calling source.load().
🧹 Nitpick comments (2)
packages/1-framework/3-tooling/cli/src/control-api/operations/contract-emit.ts (1)
81-86: Redundant manual validation — already enforced byContractSourceProviderSchema.
loadConfig()runsContractConfigSchemaviavalidateContractConfig, which requirescontract.sourceto be an object withauthoritativeInputsandload: Function. By the time this code runs,contractConfig.source.loadis guaranteed to be a function. Per the PR direction to move provider-shape validation into the Arktype schema, and per guideline to prefer assertions over defensive checks once validated, this block can be dropped.♻️ Proposed cleanup
- // Validate source exists and is callable - if (typeof contractConfig.source?.load !== 'function') { - throw errorContractConfigMissing({ - why: 'Contract config must include a valid source provider object', - }); - } -As per coding guidelines: "Use schema validators (Arktype) for structural validation of required fields, types, and shapes rather than redundant manual checks for these properties."
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/1-framework/3-tooling/cli/src/control-api/operations/contract-emit.ts` around lines 81 - 86, Remove the redundant runtime check for contractConfig.source.load in loadConfig(): since validateContractConfig runs ContractConfigSchema/ContractSourceProviderSchema and guarantees contractConfig.source.load is a Function, delete the if (typeof contractConfig.source?.load !== 'function') { throw ... } block; rely on validateContractConfig/ContractConfigSchema for enforcement and keep the rest of loadConfig() logic intact (referencing symbols: loadConfig, validateContractConfig, ContractConfigSchema, ContractSourceProviderSchema, contractConfig).packages/1-framework/3-tooling/vite-plugin-contract-emit/test/plugin.test.ts (1)
152-179: Assert the watcher registration in the moduleGraph case.This test says it registers watchers, but it only verifies
ssrLoadModule(). A regression that loads the module graph but never callswatcher.add()would still pass.🧪 Proposed test assertion
await configureServer(mockServer); expect(mockServer.ssrLoadModule).toHaveBeenCalled(); + expect(mockServer.watcher.add).toHaveBeenCalledWith('/project/prisma-next.config.ts'); });🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/1-framework/3-tooling/vite-plugin-contract-emit/test/plugin.test.ts` around lines 152 - 179, The test currently only asserts ssrLoadModule was called but must also assert the plugin registered file watchers from the module graph; after calling configureServer(mockServer) add an assertion that mockServer.watcher.add was invoked for the module file returned by mockServer.moduleGraph.getModuleById (e.g. '/project/prisma-next.config.ts') — use prismaVitePlugin, configureServer, and the mocked moduleGraph.getModuleById to locate where watcher.add should be called and assert it was called (and optionally called once).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@packages/1-framework/3-tooling/cli/test/config-types.test.ts`:
- Around line 9-12: The default parameter of createSourceProvider is too
narrowly inferred; update its signature to type the authoritativeInputs
parameter as ContractAuthoritativeInputs (imported from
`@prisma-next/config/config-types`) so it accepts all three kinds (e.g.,
'moduleGraph' and 'paths'); change the parameter annotation on
createSourceProvider to use ContractAuthoritativeInputs and add the
corresponding import statement so callers like the one at the failing call
accept the wider union type.
In `@packages/1-framework/3-tooling/vite-plugin-contract-emit/src/plugin.ts`:
- Around line 1-2: The file imports dirname and resolve from 'node:path' —
replace that import to use 'pathe' instead to ensure
cross-platform/cross-runtime compatibility; update the import that currently
reads the symbols dirname and resolve so they are imported from 'pathe' and
leave all usages of dirname and resolve in this module (plugin.ts) unchanged.
In `@packages/2-sql/2-authoring/contract-psl/src/provider.ts`:
- Around line 35-58: The loader's load function resolves the schemaPath with
resolve(schemaPath) (in load) which is cwd-relative and can differ from the
watcher that resolved authoritativeInputs.paths against the config directory;
change the resolution in load to use the same base (e.g.,
resolve(context.configDir, schemaPath) or equivalent from ContractSourceContext)
before calling readFile so the watcher and loader target the same file, and
propagate the adjusted absolute path into the notOk payload fields
(sourceId/meta.absoluteSchemaPath) so diagnostics and metadata remain
consistent; update references around load, resolve(schemaPath), readFile, and
the notOk return accordingly.
---
Outside diff comments:
In `@test/integration/test/authoring/cli.emit-parity-fixtures.test.ts`:
- Around line 95-98: The type aliases for provider result variables use
ReturnType<typeof ...contract.source> but contract.source is now an object;
change the annotations to target the load method return type instead (e.g., use
Awaited<ReturnType<typeof tsConfig.contract.source.load>> for
tsProviderResultFirst/Second and similarly use Awaited<ReturnType<typeof
pslConfig.contract.source.load>> for pslProviderResultFirst/Second and update
any diagnostics-related ReturnType references to point at .source.load as well)
so the types reflect the result of calling source.load().
In `@test/integration/test/cli.emit-command.test.ts`:
- Around line 568-570: The type annotation for sourceResult is stale because
providerConfig.contract['source'] is now an object with a load method; update
the declaration to use the load method's return type by replacing
ReturnType<NonNullable<typeof providerConfig.contract>['source']> with
ReturnType<NonNullable<typeof providerConfig.contract>['source']['load']> (keep
the NonNullable wrapper) so sourceResult correctly reflects the load result from
providerConfig.contract.source.load.
---
Nitpick comments:
In
`@packages/1-framework/3-tooling/cli/src/control-api/operations/contract-emit.ts`:
- Around line 81-86: Remove the redundant runtime check for
contractConfig.source.load in loadConfig(): since validateContractConfig runs
ContractConfigSchema/ContractSourceProviderSchema and guarantees
contractConfig.source.load is a Function, delete the if (typeof
contractConfig.source?.load !== 'function') { throw ... } block; rely on
validateContractConfig/ContractConfigSchema for enforcement and keep the rest of
loadConfig() logic intact (referencing symbols: loadConfig,
validateContractConfig, ContractConfigSchema, ContractSourceProviderSchema,
contractConfig).
In
`@packages/1-framework/3-tooling/vite-plugin-contract-emit/test/plugin.test.ts`:
- Around line 152-179: The test currently only asserts ssrLoadModule was called
but must also assert the plugin registered file watchers from the module graph;
after calling configureServer(mockServer) add an assertion that
mockServer.watcher.add was invoked for the module file returned by
mockServer.moduleGraph.getModuleById (e.g. '/project/prisma-next.config.ts') —
use prismaVitePlugin, configureServer, and the mocked moduleGraph.getModuleById
to locate where watcher.add should be called and assert it was called (and
optionally called once).
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yml
Review profile: CHILL
Plan: Pro
Run ID: bcabb0ac-ebd7-4a51-ba2a-0bf1b27bfc21
📒 Files selected for processing (57)
docs/architecture docs/adrs/ADR 163 - Provider-invoked source interpretation packages.mdpackages/1-framework/1-core/config/README.mdpackages/1-framework/1-core/config/src/config-types.tspackages/1-framework/1-core/config/src/config-validation.tspackages/1-framework/1-core/config/src/contract-source-types.tspackages/1-framework/1-core/config/src/exports/config-types.tspackages/1-framework/1-core/config/test/config-types.test-d.tspackages/1-framework/1-core/config/test/config-validation.test.tspackages/1-framework/3-tooling/cli/README.mdpackages/1-framework/3-tooling/cli/recordings/fixtures/prisma-next.config.tspackages/1-framework/3-tooling/cli/src/config-loader.tspackages/1-framework/3-tooling/cli/src/control-api/operations/contract-emit.tspackages/1-framework/3-tooling/cli/test/config-loader.test.tspackages/1-framework/3-tooling/cli/test/config-types.test.tspackages/1-framework/3-tooling/cli/test/control-api/contract-emit.test.tspackages/1-framework/3-tooling/vite-plugin-contract-emit/README.mdpackages/1-framework/3-tooling/vite-plugin-contract-emit/src/plugin.tspackages/1-framework/3-tooling/vite-plugin-contract-emit/test/plugin.test.tspackages/2-mongo-family/2-authoring/contract-psl/src/provider.tspackages/2-mongo-family/2-authoring/contract-psl/test/provider.test.tspackages/2-mongo-family/2-authoring/contract-ts/src/config-types.tspackages/2-mongo-family/2-authoring/contract-ts/test/config-types.test.tspackages/2-sql/2-authoring/contract-psl/src/provider.tspackages/2-sql/2-authoring/contract-psl/test/provider.test.tspackages/2-sql/2-authoring/contract-ts/src/config-types.tspackages/2-sql/2-authoring/contract-ts/test/config-types.test.tspackages/3-extensions/mongo/src/config/define-config.tspackages/3-extensions/mongo/test/config/define-config.test.tspackages/3-extensions/postgres/src/config/define-config.tspackages/3-extensions/postgres/test/config/define-config.test.tspackages/3-extensions/sql-orm-client/test/fixtures/prisma-next.config.tstest/integration/test/authoring/cli.emit-parity-fixtures.test.tstest/integration/test/authoring/psl.pgvector-dbinit.test.tstest/integration/test/authoring/side-by-side-contracts.test.tstest/integration/test/cli.emit-command.test.tstest/integration/test/fixtures/cli/cli-e2e-test-app/fixtures/cli-journeys/prisma-next.config.tstest/integration/test/fixtures/cli/cli-e2e-test-app/fixtures/cli-journeys/prisma-next.config.with-db.tstest/integration/test/fixtures/cli/cli-e2e-test-app/fixtures/db-init/prisma-next.config.with-db.tstest/integration/test/fixtures/cli/cli-e2e-test-app/fixtures/db-introspect/prisma-next.config.no-db.tstest/integration/test/fixtures/cli/cli-e2e-test-app/fixtures/db-introspect/prisma-next.config.no-driver.tstest/integration/test/fixtures/cli/cli-e2e-test-app/fixtures/db-introspect/prisma-next.config.with-db.tstest/integration/test/fixtures/cli/cli-e2e-test-app/fixtures/db-sign/prisma-next.config.with-db.tstest/integration/test/fixtures/cli/cli-e2e-test-app/fixtures/db-update-scenarios/prisma-next.config.with-db.tstest/integration/test/fixtures/cli/cli-e2e-test-app/fixtures/db-verify/prisma-next.config.no-driver.tstest/integration/test/fixtures/cli/cli-e2e-test-app/fixtures/db-verify/prisma-next.config.no-verify.tstest/integration/test/fixtures/cli/cli-e2e-test-app/fixtures/db-verify/prisma-next.config.tstest/integration/test/fixtures/cli/cli-e2e-test-app/fixtures/db-verify/prisma-next.config.with-db.tstest/integration/test/fixtures/cli/cli-e2e-test-app/fixtures/emit/prisma-next.config.emit.tstest/integration/test/fixtures/cli/cli-e2e-test-app/fixtures/migration-apply/prisma-next.config.with-db.tstest/integration/test/fixtures/cli/cli-e2e-test-app/fixtures/migration-plan/prisma-next.config.tstest/integration/test/fixtures/cli/cli-e2e-test-app/fixtures/mongo-db-commands/prisma-next.config.with-db.tstest/integration/test/fixtures/cli/cli-e2e-test-app/fixtures/vite-plugin/prisma-next.config.tstest/integration/test/fixtures/cli/cli-integration-test-app/fixtures/emit-command/prisma-next.config.async-source.tstest/integration/test/fixtures/cli/cli-integration-test-app/fixtures/emit-command/prisma-next.config.mongo-contract-ts.tstest/integration/test/fixtures/prisma-next.config.tstest/integration/test/mongo/fixtures/prisma-next.config.tstest/integration/test/sql-builder/fixtures/prisma-next.config.ts
✅ Files skipped from review due to trivial changes (8)
- docs/architecture docs/adrs/ADR 163 - Provider-invoked source interpretation packages.md
- packages/1-framework/3-tooling/cli/README.md
- packages/1-framework/1-core/config/src/exports/config-types.ts
- packages/3-extensions/postgres/test/config/define-config.test.ts
- packages/1-framework/3-tooling/vite-plugin-contract-emit/README.md
- packages/1-framework/3-tooling/cli/src/config-loader.ts
- packages/3-extensions/mongo/test/config/define-config.test.ts
- packages/1-framework/3-tooling/cli/test/config-loader.test.ts
🚧 Files skipped from review as they are similar to previous changes (13)
- packages/2-sql/2-authoring/contract-psl/test/provider.test.ts
- packages/2-mongo-family/2-authoring/contract-ts/test/config-types.test.ts
- packages/3-extensions/mongo/src/config/define-config.ts
- packages/1-framework/1-core/config/src/config-validation.ts
- packages/2-mongo-family/2-authoring/contract-psl/test/provider.test.ts
- packages/1-framework/1-core/config/test/config-types.test-d.ts
- packages/1-framework/1-core/config/test/config-validation.test.ts
- packages/2-mongo-family/2-authoring/contract-ts/src/config-types.ts
- packages/1-framework/1-core/config/README.md
- packages/2-sql/2-authoring/contract-ts/src/config-types.ts
- packages/2-sql/2-authoring/contract-ts/test/config-types.test.ts
- packages/3-extensions/postgres/src/config/define-config.ts
- packages/2-mongo-family/2-authoring/contract-psl/src/provider.ts
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
packages/1-framework/3-tooling/cli/test/control-api/client.test.ts (1)
467-499:⚠️ Potential issue | 🟡 MinorDuplicate of earlier test.
This test is effectively identical to the
'emits resolveSource and emit spans'case at lines 421-465 — both usecreateSourceProvider()with defaultload(returningok(...)) and assert the sameresolveSourcespan outcome. Since the provider-object shape is already the only supported shape (callable sources were removed), the "when source is a provider object" wording is redundant. Consider removing this test or, if the intent was to exercise a distinct scenario (e.g., differentauthoritativeInputskind), adjust it to cover something not already covered by the first case.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/1-framework/3-tooling/cli/test/control-api/client.test.ts` around lines 467 - 499, The test "emits resolveSource and emit spans when source is a provider object" duplicates the earlier "emits resolveSource and emit spans" case; remove this redundant test block (the it(...) that uses createSourceProvider() and asserts resolveSource spans) to avoid duplicate coverage, or if you prefer retaining a distinct case replace it with a test that exercises a different provider behavior (e.g., pass a createSourceProvider() that returns authoritativeInputs or a failing load) and assert the corresponding span outcome; locate the duplicate by the test name and the use of createSourceProvider(), client.emit(), and the resolveSource span assertions.
🧹 Nitpick comments (3)
packages/1-framework/1-core/config/src/config-types.ts (1)
89-114: Doc comment placement is now misleading.The JSDoc block at lines 89-92 describes
ContractConfigSchema, but two additional schemas (ContractAuthoritativeInputsSchema,ContractSourceProviderSchema) now sit between the comment andContractConfigSchema. Either move the comment down toContractConfigSchema(line 111) or add a short JSDoc per schema so the mapping is unambiguous.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/1-framework/1-core/config/src/config-types.ts` around lines 89 - 114, The JSDoc currently placed above ContractAuthoritativeInputsSchema is meant for ContractConfigSchema; either move that comment so it immediately precedes ContractConfigSchema or add short JSDoc comments above each schema to clarify intent — specifically update the block so ContractAuthoritativeInputsSchema, ContractSourceProviderSchema and ContractConfigSchema each have unambiguous documentation (or relocate the existing JSDoc directly above the ContractConfigSchema declaration) to resolve the misleading placement.packages/1-framework/3-tooling/vite-plugin-contract-emit/src/plugin.ts (1)
152-165: Redundant innerSetinfilterOutputArtifacts.
new Set([...new Set(values)].filter(...))wraps values in a Set, spreads to an array for filtering, then re-wraps. The outer Set already dedupes, so the inner one is pointless.- return new Set( - [...new Set(values)].filter((value) => value !== outputJsonPath && value !== outputDtsPath), - ); + return new Set( + values.filter((value) => value !== outputJsonPath && value !== outputDtsPath), + );🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/1-framework/3-tooling/vite-plugin-contract-emit/src/plugin.ts` around lines 152 - 165, filterOutputArtifacts currently wraps values in an unnecessary inner Set before filtering; replace the inner dedupe with a direct array filter and then dedupe once when constructing the returned Set. Specifically, inside filterOutputArtifacts (which uses values, contractOutput, DEFAULT_CONTRACT_OUTPUT, absoluteConfigPath, outputJsonPath, outputDtsPath) remove new Set([...new Set(values)].filter(...)) and instead filter values directly (values.filter(...)) and then wrap that filtered array in a single new Set to deduplicate the results.packages/1-framework/1-core/config/test/config-types.test-d.ts (1)
102-123: Type assertions largely restate the interface.Because
result.contract!.sourceis already typed asContractSourceProvider,expectTypeOf(...source.load).toEqualTypeOf<ContractSourceProvider['load']>()and thekindunion assertion are close to tautological: they check each field's declared type against itself rather than behavior ofdefineConfig. Consider instead asserting that the literal narrowing is preserved (e.g., constructingconfigwithas constand assertingresult.contract!.source.authoritativeInputsnarrows to{ kind: 'paths'; paths: ... }), or else asserting the input-shape is assignable toContractSourceProviderviatoExtend— those catch regressions the current assertions cannot.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/1-framework/1-core/config/test/config-types.test-d.ts` around lines 102 - 123, The test's current type assertions merely restate the declared ContractSourceProvider shape and don't verify that defineConfig preserves literal narrowing; update the test to assert narrowing or assignability instead: construct the config.authoritativeInputs with an explicit const assertion (e.g., use `as const` on the authoritativeInputs object) or build the entire config as const, then assert that result.contract!.source.authoritativeInputs has the narrowed literal type (exact `{ kind: 'paths'; paths: string[] }`) or use expectTypeOf(result.contract!.source).toExtend<ContractSourceProvider>() to confirm assignability; modify the assertions around defineConfig and result to use these stricter checks so regressions in defineConfig's type inference are caught.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@packages/1-framework/3-tooling/vite-plugin-contract-emit/src/plugin.ts`:
- Around line 217-265: resolveWatchedFiles currently omits the config file when
authoritativeInputs.kind === 'paths' and also swallows the fact that loadConfig
failed in the catch; update the 'paths' branch so the returned files Set
includes both the resolved authoritativeInputs.paths (via filterOutputArtifacts)
AND absoluteConfigPath (so edits to the config trigger a re-emit), and change
the catch block to return the PARTIAL_COVERAGE_WARNING (or otherwise a non-null
warning) instead of null while still calling logError; refer to
resolveWatchedFiles, authoritativeInputs.kind === 'paths', absoluteConfigPath,
filterOutputArtifacts, loadConfig, logError, and PARTIAL_COVERAGE_WARNING to
locate where to apply these fixes.
---
Outside diff comments:
In `@packages/1-framework/3-tooling/cli/test/control-api/client.test.ts`:
- Around line 467-499: The test "emits resolveSource and emit spans when source
is a provider object" duplicates the earlier "emits resolveSource and emit
spans" case; remove this redundant test block (the it(...) that uses
createSourceProvider() and asserts resolveSource spans) to avoid duplicate
coverage, or if you prefer retaining a distinct case replace it with a test that
exercises a different provider behavior (e.g., pass a createSourceProvider()
that returns authoritativeInputs or a failing load) and assert the corresponding
span outcome; locate the duplicate by the test name and the use of
createSourceProvider(), client.emit(), and the resolveSource span assertions.
---
Nitpick comments:
In `@packages/1-framework/1-core/config/src/config-types.ts`:
- Around line 89-114: The JSDoc currently placed above
ContractAuthoritativeInputsSchema is meant for ContractConfigSchema; either move
that comment so it immediately precedes ContractConfigSchema or add short JSDoc
comments above each schema to clarify intent — specifically update the block so
ContractAuthoritativeInputsSchema, ContractSourceProviderSchema and
ContractConfigSchema each have unambiguous documentation (or relocate the
existing JSDoc directly above the ContractConfigSchema declaration) to resolve
the misleading placement.
In `@packages/1-framework/1-core/config/test/config-types.test-d.ts`:
- Around line 102-123: The test's current type assertions merely restate the
declared ContractSourceProvider shape and don't verify that defineConfig
preserves literal narrowing; update the test to assert narrowing or
assignability instead: construct the config.authoritativeInputs with an explicit
const assertion (e.g., use `as const` on the authoritativeInputs object) or
build the entire config as const, then assert that
result.contract!.source.authoritativeInputs has the narrowed literal type (exact
`{ kind: 'paths'; paths: string[] }`) or use
expectTypeOf(result.contract!.source).toExtend<ContractSourceProvider>() to
confirm assignability; modify the assertions around defineConfig and result to
use these stricter checks so regressions in defineConfig's type inference are
caught.
In `@packages/1-framework/3-tooling/vite-plugin-contract-emit/src/plugin.ts`:
- Around line 152-165: filterOutputArtifacts currently wraps values in an
unnecessary inner Set before filtering; replace the inner dedupe with a direct
array filter and then dedupe once when constructing the returned Set.
Specifically, inside filterOutputArtifacts (which uses values, contractOutput,
DEFAULT_CONTRACT_OUTPUT, absoluteConfigPath, outputJsonPath, outputDtsPath)
remove new Set([...new Set(values)].filter(...)) and instead filter values
directly (values.filter(...)) and then wrap that filtered array in a single new
Set to deduplicate the results.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yml
Review profile: CHILL
Plan: Pro
Run ID: eccac6d8-050c-4bc2-8ab7-d7837ce7b8ea
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (22)
packages/1-framework/1-core/config/src/config-types.tspackages/1-framework/1-core/config/src/contract-source-types.tspackages/1-framework/1-core/config/test/config-types.test-d.tspackages/1-framework/3-tooling/cli/src/commands/contract-emit.tspackages/1-framework/3-tooling/cli/src/control-api/client.tspackages/1-framework/3-tooling/cli/src/control-api/operations/contract-emit.tspackages/1-framework/3-tooling/cli/src/control-api/types.tspackages/1-framework/3-tooling/cli/test/config-types.test.tspackages/1-framework/3-tooling/cli/test/control-api/client.test.tspackages/1-framework/3-tooling/vite-plugin-contract-emit/package.jsonpackages/1-framework/3-tooling/vite-plugin-contract-emit/src/plugin.tspackages/2-mongo-family/2-authoring/contract-ts/test/config-types.test.tspackages/2-sql/2-authoring/contract-psl/src/provider.tspackages/2-sql/2-authoring/contract-psl/test/fixtures.tspackages/2-sql/2-authoring/contract-psl/test/provider.test.tspackages/2-sql/2-authoring/contract-ts/test/config-types.test.tspackages/3-extensions/postgres/test/config/define-config.test.tstest/integration/test/authoring/cli.emit-parity-fixtures.test.tstest/integration/test/authoring/psl.pgvector-dbinit.test.tstest/integration/test/authoring/side-by-side-contracts.test.tstest/integration/test/cli.emit-command.test.tstest/integration/test/cli.emit-contract.test.ts
✅ Files skipped from review due to trivial changes (2)
- packages/1-framework/3-tooling/vite-plugin-contract-emit/package.json
- packages/2-sql/2-authoring/contract-psl/test/provider.test.ts
🚧 Files skipped from review as they are similar to previous changes (7)
- test/integration/test/authoring/side-by-side-contracts.test.ts
- test/integration/test/authoring/psl.pgvector-dbinit.test.ts
- test/integration/test/authoring/cli.emit-parity-fixtures.test.ts
- packages/2-sql/2-authoring/contract-ts/test/config-types.test.ts
- packages/2-sql/2-authoring/contract-psl/src/provider.ts
- packages/1-framework/3-tooling/cli/test/config-types.test.ts
- test/integration/test/cli.emit-command.test.ts
The SQL provider was updated to use context.configDir but the mongo provider was missed, causing watcher/loader path divergence when cwd differs from the config directory.
…onfigDir - Switch config-loader from node:path to pathe for consistency with the rest of the tooling layer. - Resolve .ts contract paths inside load() via context.configDir instead of capturing process.cwd() at config-definition time, so the watcher and loader always reference the same file.
The paths branch omitted the config file from the watch set, so edits to prisma-next.config.ts (e.g. changing paths or swapping provider) would not trigger re-emit. Also surface a partial-coverage warning when loadConfig fails instead of silently falling back.
System / Solution Design Review — PR #356Scope: Spec: spec.md (inferred from Linear TML-2276, PR body, and docs landed on this branch). 1. Problem & new guaranteesThe pre-change Vite plugin resolved "what to watch" by SSR-loading the user config and crawling Vite's module graph from the config entrypoint. That is authoritative only when the contract source is imported directly by the config file. Two first-class authoring flows break that assumption:
The PR establishes a new invariant: the contract source provider owns its watch metadata. Tooling must not guess, it must read Additionally, emitted artifacts ( Protocol-level concern: static inputs vs. dynamic
|
Code Review — PR #356Scope: Spec: spec.md (inferred from Linear TML-2276 and the PR body; see that document for the full acceptance-criteria list). SummaryThe PR converts What looks solid
FindingsF01 — Watch-strategy protocol is only documented in README prosepackages/1-framework/1-core/config/README.md — lines 55–58 Issue. The three-way split ( Suggestion. Add an ADR covering:
F02 —
|
| AC | Verdict | Detail |
|---|---|---|
| AC1: Built-in PSL-first providers expose their authoritative contract source paths as watch inputs | PASS | SQL: provider.ts L36–39 sets { kind: 'paths', paths: [schemaPath] } and provider.test.ts L50–53 asserts that exact shape. Mongo: same pattern in provider.ts L16–19; new dedicated test provider.test.ts asserts the full authoritativeInputs shape. |
| AC2: Config loading returns enough metadata for the Vite plugin to watch both config-driven inputs and Vite-imported TS inputs | PASS | config-loader.test.ts L72–148 round-trips paths, moduleGraph, and configPathOnly metadata through loadConfig and asserts the values. The Vite plugin reads these via plugin.ts L231–255 and branches on kind. Plugin tests (plugin.test.ts L152–217) verify both the moduleGraph crawl path and the explicit paths path add the right files to the watcher. |
| AC3: Custom providers can declare additional watch inputs explicitly | PASS | ContractConfigSchema in config-types.ts L93–114 accepts any provider object with a paths: string[] array. config-validation.test.ts L346–388 asserts that malformed shapes (missing paths, unknown kind, wrong types) throw structured errors. The type-level config-types.test-d.ts L102–123 proves the public type accepts a user-authored { kind: 'paths', paths: [...] } provider. |
| AC4: If custom providers omit watch inputs, the system falls back to watching the config path and emits a dev warning that coverage is partial | PASS | plugin.ts L257–260 returns files: new Set([absoluteConfigPath]) with PARTIAL_COVERAGE_WARNING when authoritativeInputs.kind === 'configPathOnly'. plugin.test.ts L271–295 asserts both that only the config path is added to the watcher and that console.warn is invoked with a message containing 'configPathOnly'. Note: finding F02 points out that the same warning text is also emitted when loadConfig itself fails, which confuses the signal but does not contradict the AC. |
| AC5: Output artifact paths are not reported as source watch inputs | PASS (consumer-side only) | Satisfied by filterOutputArtifacts (plugin.ts L152–165) silently dropping the output paths from the watched set. However, the AC is stated as a system property (outputs never flow in as inputs). In current code this is enforced only at the consumer — no provider today emits output paths, no validation rejects them if one did. The positive test (plugin.test.ts L181–217) documents that the filter fires but also demonstrates that the protocol permits a provider to declare outputs as inputs without error. See F18 for the recommendation to enforce at validation time. |
Summary
| Result | Count | ACs |
|---|---|---|
| PASS | 5 | AC1, AC2, AC3, AC4, AC5 |
| FAIL | 0 | — |
| NOT VERIFIED | 0 | — |
| WEAK | 0 | — |
All acceptance criteria are verified by tests that actually assert the required behavior. The architectural gap is the absence of an end-to-end test that exercises a real Vite dev server lifecycle (covered as D1). Unit-mock verification is sufficient for AC pass, but not for high confidence against the broader VP3 stop condition.
Close D1 from the PR #356 review by driving a real Vite dev server through both scenarios that were previously only unit-mocked: modifying `contract.prisma` re-emits the contract, and editing the config to swap the declared PSL input re-emits against the new file.
Align with the Mongo PSL provider and with the parser step's sourceId. The absolute form stays accessible via meta.absoluteSchemaPath for downstream consumers that need it.
Collapse the ~20-line inline provider that postgres and mongo facades each build around a dynamic import of the user's `contract.ts`. The logic (path resolution, pathToFileURL, default-export extraction) is family-agnostic, so each contract-ts package exposes it as a sibling to typescriptContract.
- handleTrackedFileChange now runs ctx.file through pathe.resolve before comparing against watchedFiles / ignoredOutputFiles, so symlinked or case-folded paths line up with the resolved entries. - resolveContractOutputFiles no longer falls back to the hardcoded 'src/prisma/contract.json' when contract.output is missing. The filter simply skips; defineConfig() guarantees output is present in the happy path, and raw-object configs get a clean no-op instead of a path the CLI never actually writes.
…ceContext Left over from the split that moved configDir out of ContractSourceContext into ContractSourceEnvironment — the context builder no longer needs it.
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (5)
test/integration/test/vite-plugin.hmr.e2e.test.ts (2)
108-113: Duplicated module-graph invalidation pattern — consider extracting a helper.The
getModulesByFile(...) + for-loop invalidateModule(...)block is repeated verbatim in two tests (and thechangeemit follows each). A small helper likeinvalidateAndEmitChange(server, filePath)would reduce duplication and clarify intent. Optional; not blocking.Also applies to: 252-257
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test/integration/test/vite-plugin.hmr.e2e.test.ts` around lines 108 - 113, Extract the repeated pattern that calls server.moduleGraph.getModulesByFile(filePath) and then loops calling server.moduleGraph.invalidateModule(module) followed by emitting the change into a small helper (e.g., invalidateAndEmitChange(server, filePath)); implement the helper so it retrieves modules for the given filePath, invalidates each via invalidateModule, and then performs the same "change" emit used in the tests, then replace both duplicated blocks (the one around contractPath and the one at the other occurrence) with calls to invalidateAndEmitChange(server, contractPath) (or the appropriate filePath) to remove duplication and clarify intent.
210-310: Consider splitting the "config changes the authoritative inputs" test into two cases.This single
itexercises two distinct behaviors back‑to‑back: (1) switching the referenced schema via avite.config.tsedit triggers a re‑emit using the new inputs, and (2) subsequent edits tocontract-alt.prismaare now watched. Splitting them into nesteddescribeblocks (e.g. given config switched to contract-alt.prisma → when config edited → then re-emits / …and when alt schema edited → then re-emits) would make each assertion read as a standalone behavior and produce more actionable failure messages if only one phase breaks.As per coding guidelines: "Group test assertions by the conditions under which they're true using nested
describe()blocks to model state and transitions (given/when/then structure)".🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test/integration/test/vite-plugin.hmr.e2e.test.ts` around lines 210 - 310, The long test "re-emits contract when config changes the authoritative inputs" exercises two behaviors and should be split: extract the first phase (editing vite.config.ts to switch './contract.prisma' → './contract-alt.prisma' and asserting the contract reflects 'name' nullable) into its own test (use the same setupTestDirectoryFromFixtures, createServer, waitForFileChange logic and assertions) and create a second test that either repeats the setup or begins by performing the config switch (you can reuse the helper calls: replaceInFileOrThrow(configPath, './contract.prisma', './contract-alt.prisma'), invalidate modules via server.moduleGraph.getModulesByFile(configPath) and server.watcher.emit('change', configPath)) and then edits altSchemaPath (replaceInFileOrThrow(altSchemaPath, ' name String?\n', ' name String?\n nickname String?\n')) and asserts the subsequent re-emit contains 'nickname'; keep the same waitForFileChange/expect flows and timeouts (timeouts.typeScriptCompilation, timeouts.spinUpPpgDev) and reference the existing symbols like replaceInFileOrThrow, waitForFileChange, server.moduleGraph.getModulesByFile, server.watcher.emit to locate where to split and duplicate required setup/teardown.packages/1-framework/1-core/config/src/config-types.ts (1)
89-96: UseSchema.array()for the Arktypeinputsarray.Line 90 uses the string shorthand; the repo convention is to define arrays through
.array().♻️ Proposed refactor
+const ContractSourceInputSchema = type('string'); + export const ContractSourceProviderSchema = type({ - 'inputs?': 'string[]', + 'inputs?': ContractSourceInputSchema.array(), load: 'Function', });As per coding guidelines, use
Schema.array()for array definitions in Arktype schemas.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/1-framework/1-core/config/src/config-types.ts` around lines 89 - 96, The ContractSourceProviderSchema currently uses the string shorthand for the optional inputs array ('inputs?': 'string[]'); update it to use Arktype's Schema.array() form instead so it follows repo convention: replace the 'inputs?' shorthand in the ContractSourceProviderSchema definition with Schema.array(Schema.string()). Also ensure the import/usage matches other schemas and that the optional marker remains (i.e., keep inputs optional) in the ContractSourceProviderSchema and does not change ContractConfigSchema.packages/1-framework/1-core/config/test/config-validation.test.ts (1)
464-476: Split this test file before adding more coverage.This test file now reaches Line 519, exceeding the 500-line limit. Since it already has distinct top-level groups (
validateConfig,ConfigValidationError,defineConfig), consider moving thedefineConfigcoverage into a focused sibling test file.As per coding guidelines,
**/*.test.ts: Keep test files under 500 lines to maintain readability and navigability.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/1-framework/1-core/config/test/config-validation.test.ts` around lines 464 - 476, This test file exceeds the 500-line limit; move the tests that target defineConfig (including the "preserves source provider metadata" case and any other defineConfig-specific tests) into a new sibling test file so each top-level group (validateConfig, ConfigValidationError, defineConfig) lives in its own file; locate tests referencing defineConfig, create a new test file containing the describe/it blocks that reference defineConfig (and helper calls like createValidConfig and createSourceProvider), update imports so defineConfig, createValidConfig, createSourceProvider remain resolved, and remove those tests from the original file to keep both files under 500 lines.packages/1-framework/1-core/config/src/contract-source-types.ts (1)
47-56: Document the provider path contract at the public interface.
inputsis now a tooling protocol, but the type does not state whether relative paths are resolved fromconfigDir, whether entries are direct provider reads vs transitive imports, or that generated outputs must not be listed.Suggested TSDoc
export interface ContractSourceEnvironment { + /** + * Directory containing the loaded Prisma Next config file. Providers should + * resolve relative source paths from this directory. + */ readonly configDir: string; } export interface ContractSourceProvider { + /** + * Authoritative files read directly by this provider. Relative entries are + * resolved from `ContractSourceEnvironment.configDir`; generated output + * artifacts must not be listed here. + */ readonly inputs?: readonly string[]; + /** + * Loads the contract using domain context plus environment-specific I/O data. + */ readonly load: (As per coding guidelines,
**/*.{md,ts,tsx}: Keep docs current.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/1-framework/1-core/config/src/contract-source-types.ts` around lines 47 - 56, Update the public interface docs for ContractSourceProvider and ContractSourceEnvironment: add TSDoc on ContractSourceEnvironment.configDir to state it is the base directory for resolving relative provider input paths; add TSDoc on ContractSourceProvider.inputs to note this is a tooling protocol (not user-facing), that each entry is a direct provider input (not transitive imports), that relative paths are resolved against configDir, and explicitly prohibit listing generated/derived outputs in inputs; also document the load(context, environment) contract expectations regarding inputs resolution and diagnostics reporting.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@packages/1-framework/1-core/config/src/config-validation.ts`:
- Around line 23-47: The current validation allows sourceConfig['inputs'] to
include the same path as contract['output'], which can create self-trigger
loops; update the inputs validation in the block that iterates over
sourceConfig['inputs'] to check for and reject any entry equal to
contract['output'] (or equal after normalizing paths if your project uses
relative paths) by calling throwValidation (e.g.,
throwValidation('contract.source.inputs[]', 'Config.contract.source.inputs must
not include the emitted artifact path specified by contract.output')); use the
existing sourceConfig, contract and throwValidation symbols to locate and
implement this guard.
---
Nitpick comments:
In `@packages/1-framework/1-core/config/src/config-types.ts`:
- Around line 89-96: The ContractSourceProviderSchema currently uses the string
shorthand for the optional inputs array ('inputs?': 'string[]'); update it to
use Arktype's Schema.array() form instead so it follows repo convention: replace
the 'inputs?' shorthand in the ContractSourceProviderSchema definition with
Schema.array(Schema.string()). Also ensure the import/usage matches other
schemas and that the optional marker remains (i.e., keep inputs optional) in the
ContractSourceProviderSchema and does not change ContractConfigSchema.
In `@packages/1-framework/1-core/config/src/contract-source-types.ts`:
- Around line 47-56: Update the public interface docs for ContractSourceProvider
and ContractSourceEnvironment: add TSDoc on ContractSourceEnvironment.configDir
to state it is the base directory for resolving relative provider input paths;
add TSDoc on ContractSourceProvider.inputs to note this is a tooling protocol
(not user-facing), that each entry is a direct provider input (not transitive
imports), that relative paths are resolved against configDir, and explicitly
prohibit listing generated/derived outputs in inputs; also document the
load(context, environment) contract expectations regarding inputs resolution and
diagnostics reporting.
In `@packages/1-framework/1-core/config/test/config-validation.test.ts`:
- Around line 464-476: This test file exceeds the 500-line limit; move the tests
that target defineConfig (including the "preserves source provider metadata"
case and any other defineConfig-specific tests) into a new sibling test file so
each top-level group (validateConfig, ConfigValidationError, defineConfig) lives
in its own file; locate tests referencing defineConfig, create a new test file
containing the describe/it blocks that reference defineConfig (and helper calls
like createValidConfig and createSourceProvider), update imports so
defineConfig, createValidConfig, createSourceProvider remain resolved, and
remove those tests from the original file to keep both files under 500 lines.
In `@test/integration/test/vite-plugin.hmr.e2e.test.ts`:
- Around line 108-113: Extract the repeated pattern that calls
server.moduleGraph.getModulesByFile(filePath) and then loops calling
server.moduleGraph.invalidateModule(module) followed by emitting the change into
a small helper (e.g., invalidateAndEmitChange(server, filePath)); implement the
helper so it retrieves modules for the given filePath, invalidates each via
invalidateModule, and then performs the same "change" emit used in the tests,
then replace both duplicated blocks (the one around contractPath and the one at
the other occurrence) with calls to invalidateAndEmitChange(server,
contractPath) (or the appropriate filePath) to remove duplication and clarify
intent.
- Around line 210-310: The long test "re-emits contract when config changes the
authoritative inputs" exercises two behaviors and should be split: extract the
first phase (editing vite.config.ts to switch './contract.prisma' →
'./contract-alt.prisma' and asserting the contract reflects 'name' nullable)
into its own test (use the same setupTestDirectoryFromFixtures, createServer,
waitForFileChange logic and assertions) and create a second test that either
repeats the setup or begins by performing the config switch (you can reuse the
helper calls: replaceInFileOrThrow(configPath, './contract.prisma',
'./contract-alt.prisma'), invalidate modules via
server.moduleGraph.getModulesByFile(configPath) and
server.watcher.emit('change', configPath)) and then edits altSchemaPath
(replaceInFileOrThrow(altSchemaPath, ' name String?\n', ' name String?\n
nickname String?\n')) and asserts the subsequent re-emit contains 'nickname';
keep the same waitForFileChange/expect flows and timeouts
(timeouts.typeScriptCompilation, timeouts.spinUpPpgDev) and reference the
existing symbols like replaceInFileOrThrow, waitForFileChange,
server.moduleGraph.getModulesByFile, server.watcher.emit to locate where to
split and duplicate required setup/teardown.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yml
Review profile: CHILL
Plan: Pro
Run ID: a084229c-376c-4c8e-b83c-11dd50ea2fc5
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (72)
packages/1-framework/1-core/config/README.mdpackages/1-framework/1-core/config/src/config-types.tspackages/1-framework/1-core/config/src/config-validation.tspackages/1-framework/1-core/config/src/contract-source-types.tspackages/1-framework/1-core/config/src/exports/config-types.tspackages/1-framework/1-core/config/test/config-types.test-d.tspackages/1-framework/1-core/config/test/config-validation.test.tspackages/1-framework/3-tooling/cli/README.mdpackages/1-framework/3-tooling/cli/recordings/fixtures/prisma-next.config.tspackages/1-framework/3-tooling/cli/src/config-loader.tspackages/1-framework/3-tooling/cli/src/control-api/client.tspackages/1-framework/3-tooling/cli/src/control-api/operations/contract-emit.tspackages/1-framework/3-tooling/cli/src/exports/config-types.tspackages/1-framework/3-tooling/cli/test/config-loader.test.tspackages/1-framework/3-tooling/cli/test/config-types.test.tspackages/1-framework/3-tooling/cli/test/control-api/client.test.tspackages/1-framework/3-tooling/cli/test/control-api/contract-emit.test.tspackages/1-framework/3-tooling/vite-plugin-contract-emit/README.mdpackages/1-framework/3-tooling/vite-plugin-contract-emit/src/plugin.tspackages/1-framework/3-tooling/vite-plugin-contract-emit/test/plugin.test.tspackages/2-mongo-family/2-authoring/contract-psl/src/provider.tspackages/2-mongo-family/2-authoring/contract-psl/test/provider.test.tspackages/2-mongo-family/2-authoring/contract-ts/package.jsonpackages/2-mongo-family/2-authoring/contract-ts/src/config-types.tspackages/2-mongo-family/2-authoring/contract-ts/src/exports/config-types.tspackages/2-mongo-family/2-authoring/contract-ts/test/config-types.test.tspackages/2-sql/2-authoring/contract-psl/src/provider.tspackages/2-sql/2-authoring/contract-psl/test/fixtures.tspackages/2-sql/2-authoring/contract-psl/test/provider.test.tspackages/2-sql/2-authoring/contract-ts/package.jsonpackages/2-sql/2-authoring/contract-ts/src/config-types.tspackages/2-sql/2-authoring/contract-ts/src/exports/config-types.tspackages/2-sql/2-authoring/contract-ts/test/config-types.test.tspackages/3-extensions/mongo/src/config/define-config.tspackages/3-extensions/mongo/test/config/define-config.test.tspackages/3-extensions/postgres/src/config/define-config.tspackages/3-extensions/postgres/test/config/define-config.test.tspackages/3-extensions/sql-orm-client/test/fixtures/prisma-next.config.tstest/integration/test/authoring/cli.emit-parity-fixtures.test.tstest/integration/test/authoring/parity/callback-mode-scalars/contract.tstest/integration/test/authoring/psl.pgvector-dbinit.test.tstest/integration/test/authoring/side-by-side-contracts.test.tstest/integration/test/cli.emit-command.test.tstest/integration/test/cli.emit-contract.test.tstest/integration/test/fixtures/cli/cli-e2e-test-app/fixtures/cli-journeys/prisma-next.config.tstest/integration/test/fixtures/cli/cli-e2e-test-app/fixtures/cli-journeys/prisma-next.config.with-db.tstest/integration/test/fixtures/cli/cli-e2e-test-app/fixtures/db-init/prisma-next.config.with-db.tstest/integration/test/fixtures/cli/cli-e2e-test-app/fixtures/db-introspect/prisma-next.config.no-db.tstest/integration/test/fixtures/cli/cli-e2e-test-app/fixtures/db-introspect/prisma-next.config.no-driver.tstest/integration/test/fixtures/cli/cli-e2e-test-app/fixtures/db-introspect/prisma-next.config.with-db.tstest/integration/test/fixtures/cli/cli-e2e-test-app/fixtures/db-sign/prisma-next.config.with-db.tstest/integration/test/fixtures/cli/cli-e2e-test-app/fixtures/db-update-scenarios/prisma-next.config.with-db.tstest/integration/test/fixtures/cli/cli-e2e-test-app/fixtures/db-verify/prisma-next.config.no-driver.tstest/integration/test/fixtures/cli/cli-e2e-test-app/fixtures/db-verify/prisma-next.config.no-verify.tstest/integration/test/fixtures/cli/cli-e2e-test-app/fixtures/db-verify/prisma-next.config.tstest/integration/test/fixtures/cli/cli-e2e-test-app/fixtures/db-verify/prisma-next.config.with-db.tstest/integration/test/fixtures/cli/cli-e2e-test-app/fixtures/emit/prisma-next.config.emit.tstest/integration/test/fixtures/cli/cli-e2e-test-app/fixtures/migration-apply/prisma-next.config.with-db.tstest/integration/test/fixtures/cli/cli-e2e-test-app/fixtures/migration-plan/prisma-next.config.tstest/integration/test/fixtures/cli/cli-e2e-test-app/fixtures/mongo-db-commands/prisma-next.config.with-db.tstest/integration/test/fixtures/cli/cli-e2e-test-app/fixtures/vite-plugin-psl/contract-alt.prismatest/integration/test/fixtures/cli/cli-e2e-test-app/fixtures/vite-plugin-psl/contract.prismatest/integration/test/fixtures/cli/cli-e2e-test-app/fixtures/vite-plugin-psl/prisma-next.config.tstest/integration/test/fixtures/cli/cli-e2e-test-app/fixtures/vite-plugin-psl/vite.config.tstest/integration/test/fixtures/cli/cli-e2e-test-app/fixtures/vite-plugin/prisma-next.config.tstest/integration/test/fixtures/cli/cli-integration-test-app/fixtures/emit-command/prisma-next.config.async-source.tstest/integration/test/fixtures/cli/cli-integration-test-app/fixtures/emit-command/prisma-next.config.mongo-contract-ts.tstest/integration/test/fixtures/prisma-next.config.tstest/integration/test/mongo/fixtures/prisma-next.config.tstest/integration/test/sql-builder/fixtures/prisma-next.config.tstest/integration/test/vite-plugin.hmr.e2e.test.tstest/utils/package.json
✅ Files skipped from review due to trivial changes (20)
- packages/2-sql/2-authoring/contract-ts/src/exports/config-types.ts
- test/integration/test/fixtures/cli/cli-e2e-test-app/fixtures/emit/prisma-next.config.emit.ts
- test/integration/test/mongo/fixtures/prisma-next.config.ts
- packages/2-sql/2-authoring/contract-ts/package.json
- test/integration/test/fixtures/cli/cli-e2e-test-app/fixtures/vite-plugin-psl/contract.prisma
- test/integration/test/fixtures/cli/cli-e2e-test-app/fixtures/vite-plugin-psl/contract-alt.prisma
- test/integration/test/fixtures/cli/cli-e2e-test-app/fixtures/db-verify/prisma-next.config.ts
- packages/2-mongo-family/2-authoring/contract-psl/test/provider.test.ts
- packages/1-framework/1-core/config/test/config-types.test-d.ts
- test/integration/test/authoring/psl.pgvector-dbinit.test.ts
- packages/2-sql/2-authoring/contract-ts/test/config-types.test.ts
- packages/1-framework/3-tooling/cli/test/control-api/contract-emit.test.ts
- packages/1-framework/3-tooling/cli/test/config-loader.test.ts
- test/integration/test/fixtures/cli/cli-e2e-test-app/fixtures/db-update-scenarios/prisma-next.config.with-db.ts
- test/integration/test/fixtures/cli/cli-e2e-test-app/fixtures/db-introspect/prisma-next.config.with-db.ts
- packages/2-sql/2-authoring/contract-psl/test/provider.test.ts
- test/integration/test/fixtures/cli/cli-e2e-test-app/fixtures/cli-journeys/prisma-next.config.with-db.ts
- packages/1-framework/3-tooling/vite-plugin-contract-emit/README.md
- packages/1-framework/3-tooling/cli/src/exports/config-types.ts
- packages/2-mongo-family/2-authoring/contract-ts/package.json
🚧 Files skipped from review as they are similar to previous changes (34)
- packages/1-framework/3-tooling/cli/recordings/fixtures/prisma-next.config.ts
- packages/1-framework/1-core/config/src/exports/config-types.ts
- packages/3-extensions/sql-orm-client/test/fixtures/prisma-next.config.ts
- test/integration/test/authoring/side-by-side-contracts.test.ts
- test/integration/test/fixtures/cli/cli-e2e-test-app/fixtures/vite-plugin/prisma-next.config.ts
- test/integration/test/fixtures/cli/cli-e2e-test-app/fixtures/mongo-db-commands/prisma-next.config.with-db.ts
- test/integration/test/fixtures/cli/cli-integration-test-app/fixtures/emit-command/prisma-next.config.async-source.ts
- packages/2-sql/2-authoring/contract-psl/test/fixtures.ts
- test/integration/test/fixtures/cli/cli-e2e-test-app/fixtures/db-init/prisma-next.config.with-db.ts
- packages/3-extensions/mongo/src/config/define-config.ts
- test/integration/test/fixtures/prisma-next.config.ts
- test/integration/test/fixtures/cli/cli-e2e-test-app/fixtures/db-sign/prisma-next.config.with-db.ts
- test/integration/test/fixtures/cli/cli-e2e-test-app/fixtures/cli-journeys/prisma-next.config.ts
- packages/3-extensions/postgres/src/config/define-config.ts
- packages/1-framework/3-tooling/cli/README.md
- packages/3-extensions/postgres/test/config/define-config.test.ts
- test/integration/test/fixtures/cli/cli-e2e-test-app/fixtures/migration-plan/prisma-next.config.ts
- test/integration/test/fixtures/cli/cli-e2e-test-app/fixtures/db-introspect/prisma-next.config.no-db.ts
- test/integration/test/fixtures/cli/cli-e2e-test-app/fixtures/db-verify/prisma-next.config.with-db.ts
- test/integration/test/cli.emit-contract.test.ts
- packages/1-framework/3-tooling/cli/test/control-api/client.test.ts
- test/integration/test/fixtures/cli/cli-e2e-test-app/fixtures/db-verify/prisma-next.config.no-verify.ts
- packages/1-framework/3-tooling/cli/src/config-loader.ts
- test/integration/test/authoring/cli.emit-parity-fixtures.test.ts
- packages/2-mongo-family/2-authoring/contract-ts/src/config-types.ts
- packages/2-mongo-family/2-authoring/contract-psl/src/provider.ts
- packages/2-sql/2-authoring/contract-ts/src/config-types.ts
- test/integration/test/fixtures/cli/cli-integration-test-app/fixtures/emit-command/prisma-next.config.mongo-contract-ts.ts
- test/integration/test/fixtures/cli/cli-e2e-test-app/fixtures/db-introspect/prisma-next.config.no-driver.ts
- test/integration/test/fixtures/cli/cli-e2e-test-app/fixtures/db-verify/prisma-next.config.no-driver.ts
- packages/3-extensions/mongo/test/config/define-config.test.ts
- test/integration/test/fixtures/cli/cli-e2e-test-app/fixtures/migration-apply/prisma-next.config.with-db.ts
- packages/1-framework/3-tooling/vite-plugin-contract-emit/src/plugin.ts
- packages/1-framework/3-tooling/vite-plugin-contract-emit/test/plugin.test.ts
There was a problem hiding this comment.
🧹 Nitpick comments (1)
packages/1-framework/1-core/config/test/config-validation.test.ts (1)
335-397: ReusecreateSourceProviderhelper to reduce duplication.The inline
source: { inputs: ..., load: async () => ok({ targetFamily: 'sql' } as Contract) }pattern is repeated four times. SincecreateSourceProvideralready accepts arbitrary overrides, these cases can use it to eliminate the duplicatedloadliteral and match the helper-based style used elsewhere in the file.♻️ Example refactor
- contract: { - source: { - inputs: 123, - load: async () => ok({ targetFamily: 'sql' } as Contract), - }, - }, + contract: { + source: createSourceProvider({ inputs: 123 }), + },Apply the same pattern to the
['valid', 123],['./generated/contract.json'], and['./generated/contract.d.ts']cases.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/1-framework/1-core/config/test/config-validation.test.ts` around lines 335 - 397, Replace the repeated inline source objects in the tests with the existing helper by using createSourceProvider to build the contract.source value: for each expectFieldError call that currently passes contract: { source: { inputs: <...>, load: async () => ok({ targetFamily: 'sql' } as Contract) } } (and the two cases that add output), call createValidRawConfig({ contract: { source: createSourceProvider({ inputs: <...> }), output: ...? } }) instead; this reuses the load implementation from createSourceProvider and removes the duplicated load literal while keeping expectFieldError and createValidRawConfig unchanged.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@packages/1-framework/1-core/config/test/config-validation.test.ts`:
- Around line 335-397: Replace the repeated inline source objects in the tests
with the existing helper by using createSourceProvider to build the
contract.source value: for each expectFieldError call that currently passes
contract: { source: { inputs: <...>, load: async () => ok({ targetFamily: 'sql'
} as Contract) } } (and the two cases that add output), call
createValidRawConfig({ contract: { source: createSourceProvider({ inputs: <...>
}), output: ...? } }) instead; this reuses the load implementation from
createSourceProvider and removes the duplicated load literal while keeping
expectFieldError and createValidRawConfig unchanged.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yml
Review profile: CHILL
Plan: Pro
Run ID: 68cb01b4-4682-421a-add3-7dbd0c8942a2
📒 Files selected for processing (5)
packages/1-framework/1-core/config/README.mdpackages/1-framework/1-core/config/src/config-validation.tspackages/1-framework/1-core/config/test/config-validation.test.tspackages/1-framework/3-tooling/cli/test/config-loader.test.tstest/integration/test/cli.emit-contract.test.ts
🚧 Files skipped from review as they are similar to previous changes (3)
- test/integration/test/cli.emit-contract.test.ts
- packages/1-framework/1-core/config/src/config-validation.ts
- packages/1-framework/1-core/config/README.md
Re-review — most of the feedback is addressedThanks for the substantial rework. The protocol is in a much better shape now. Biggest wins since the last round
What's still liveTwo new items surfaced by the re-review:
Still-live from the previous round (downgraded where appropriate):
Nothing in the still-live list is a merge blocker. AC4 / R01 is the only item I'd prefer to see a thread on before landing — a one-liner in the PR body explaining the intentional drift, or a short startup sanity warning, would be enough. |
|
Addressed the two remaining re-review items:
I also resolved the stale outdated review threads that were already addressed by the current branch. @wmadden can you take another look? |
2 participants
Why
The Vite auto-emit flow was relying on the config module graph as the source of truth for invalidation.
That breaks in two supported authoring paths:
./prisma/schema.prismaas strings to provider helpers, so those files never appear in the config module graph.contract: './prisma/contract.ts'load that file later insidecontract.source.load()via dynamic import, so the config module graph still does not see the actual contract file.Without explicit source declarations from providers, those edits do not reliably trigger re-emission during
vite dev.What this PR does
This PR moves authoritative source declarations onto the contract source provider and keeps watcher-specific behavior in the Vite integration.
It does that by:
contract.sourcefrom a bare async function into a provider object with optionalinputsplusload(context, environment)ContractSourceContextinto a newContractSourceEnvironmentthat carriesconfigDirinputsfor built-in SQL and Mongo PSL providers with their schema pathsinputsfor the postgres and mongo.tsfacades with the user-declared contract path they dynamic-importtypescriptContractFromPath()so the.tspath-loading logic is shared and resolves relative toconfigDirloadConfig()APIConfig shape change
load()now receives:context: the existing domain inputs (codec lookup, authoring contributions, mutation defaults, ...)environment: file-system execution context, currentlyconfigDirDeclare
source.inputsonly for source files that are not already covered by the config module graph, such as PSL schema paths and TypeScript contract paths passed as strings.Omitted
inputssemanticsFor providers that omit
source.inputs, the current behavior is intentional: the Vite plugin falls back to watching the config file plus the config module graph.This PR does not emit a partial-coverage warning in that case. That is sufficient for TS-authored providers whose real sources are already reachable from the module graph, but any custom provider that reads extra non-module-graph files must declare those files in
source.inputs.Summary
contract.source.inputs?: readonly string[]contract.source(context)withcontract.source.load(context, environment)ContractSourceEnvironmentwithconfigDirconfigDirinstead ofprocess.cwd()inputsfor built-in SQL and Mongo PSL providers and for postgres/mongo.tsfacadestypescriptContractFromPath()to share.tsdynamic-import logicloadConfig()surface; no metadata-returning loader variantcontract.json/contract.d.tsdo not loop back into auto-emitBreaking change
Every user config migrates from:
to:
configDirno longer lives onContractSourceContext; providers receive it through the secondenvironmentargument.Known limitation
Default
contract.outputfallback still relies ondefineConfig(). Raw object configs that omitcontract.outputare not normalized byloadConfig()in this PR.Testing
pnpm --filter ./packages/1-framework/1-core/config testpnpm --filter ./packages/1-framework/3-tooling/cli test -- test/config-loader.test.ts test/config-types.test.ts test/control-api/contract-emit.test.tspnpm --filter ./packages/1-framework/3-tooling/vite-plugin-contract-emit test -- test/plugin.test.tspnpm --filter ./packages/2-sql/2-authoring/contract-psl test -- test/provider.test.tspnpm --filter ./packages/2-mongo-family/2-authoring/contract-psl testpnpm --filter ./packages/2-mongo-family/2-authoring/contract-ts testpnpm --filter ./packages/3-extensions/postgres test -- test/config/define-config.test.tspnpm --filter ./packages/3-extensions/mongo test -- test/config/define-config.test.tspnpm --filter ./test/integration exec vitest run test/vite-plugin.hmr.e2e.test.tspnpm --filter ./test/integration exec vitest run test/cli.emit-command.test.tsCloses
TML-2276
Summary by CodeRabbit
Release Notes
New Features
inputsmetadata for better tooling integration.Documentation
Chores
loadmethod for improved extensibility.