test(vite): add HMR recovery coverage for invalid PSL edits#366
test(vite): add HMR recovery coverage for invalid PSL edits#366
Conversation
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.
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.
`loadConfig()` now owns config-file-relative path resolution for `contract.source.inputs` and `contract.output`, and enforces that no declared input equals an emitted artifact path. Extension facades (postgres, mongo `define-config`) propagate the new context shape to providers; control-api call sites thread resolved inputs through.
Introduces `getEmittedArtifactPaths()` so `contract.json` / `contract.d.ts` paths are derived from `contract.output` in one place. `emit()` takes the output path and uses the helper, replacing the duplicated derivation that had grown across config, CLI, and Vite.
SQL and Mongo PSL providers read absolute paths from `context.resolvedInputs` instead of resolving schema paths themselves; they fail loudly when the list is empty rather than silently defaulting. TypeScript contract facades gain a `typescriptContractFromPath` helper so both families share path handling.
Plugin reads absolute inputs from the loader-finalized config instead of re-resolving them; the config file itself is watched in paths mode and a warning fires on load failure. Hot-update paths are normalized via `pathe` so the plugin stops fabricating default outputs for unrelated files.
…rdening Updates all `prisma-next.config.ts` fixtures under test/integration to the new `contract.source.inputs` shape. Adds the vite-plugin PSL fixture used by the HMR e2e test and makes that test wait until the rewritten `contract.json` is readable before parsing. Raises timeout budgets on DB-backed CLI and sql-builder integration tests that were flaky under full- repo load.
Updates ADR 163 to describe provider-invoked source interpretation with the resolvedInputs I/O boundary, and aligns the config / cli / vite-plugin READMEs with the current `load()` signature and the one-call-site path derivation.
…ma/prisma-next into tml-2276-authoritative-watch-inputs
…uts' into tml-2277-vite-plugin-watch-behavior
…watch-behavior # Conflicts: # packages/1-framework/3-tooling/cli/src/config-path-validation.ts # packages/1-framework/3-tooling/cli/test/config-loader.test.ts # packages/1-framework/3-tooling/vite-plugin-contract-emit/README.md # 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
Extend the Vite plugin HMR integration suite with a PSL recovery journey. The new test proves a bad edit preserves the last good artifacts on disk and that a subsequent valid edit re-emits both contract files. Refs TML-2293
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 6 minutes and 39 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
✨ Finishing Touches🧪 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/ts-render
@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-query-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: |
Add two short comments to the Vite HMR recovery integration test so the intentional failure phase and the expected recovery phase are easier to scan in review.
…test-coverage # Conflicts: # packages/1-framework/3-tooling/cli/src/config-path-validation.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
Summary
Testing
Notes