Does it support drizzle orm v1 RC?

[anthonyhoegberg]

Use case

So im not quite sure since i just found this, looks nice and all im just wondering if it supports RC 1 of drizzle orm since that will probably be released soon.
https://github.com/drizzle-team/drizzle-orm/releases/tag/v1.0.0-rc.4
is the current latest one

If im wrong im sorry and maybe just close the issue, and add in docs section whats different if any?

Current approach

Current one is using non RC version of drizzle

Proposed change

Add RC V1 support

Change type

other

Project boundaries

• This keeps standard Drizzle schemas and query builders visible.
• This does not make optional validation or driver ecosystems mandatory.
• This fits normal Nest module, provider, lifecycle, and testing patterns.

[rodrigobnogueira]

Hi @anthonyhoegberg . Thanks for bringing this up.

Short answer: not yet, and it's blocked on the wider Drizzle ecosystem rather than on this package.

Current support

The peer range is drizzle-orm >=0.30.0 <2.0.0; CI and the default install run on the stable line (0.45.2, which is still Drizzle's latest). v1 is at 1.0.0-rc.4 under the npm rc tag.

What I found testing against drizzle-orm@1.0.0-rc.4

@nest-native/drizzle itself carries no dependency on Drizzle internals — it treats your client as an opaque value — so the module, DI, repositories, and the transaction/testing bridges are structurally v1-ready. The blockers are downstream:

• RQB v2 config change. v1 drops the drizzle(client, { schema }) config shape (schema/relations moved to the new relations API), so schema-typed clients like LibSQLDatabase<typeof schema> and the driver/integration tests no longer type-check without changes. DrizzleSQLiteConfig / DrizzlePgConfig / DrizzleMySqlConfig reject the schema key now.
• Transactional adapter. @nestjs-cls/transactional-adapter-drizzle-orm (latest 1.3.0) peer-pins drizzle-orm@^0, so @Transactional() / @InjectTransaction() can't run on v1 until that adapter ships a v1 build. Installing v1 alongside it today requires --legacy-peer-deps.
• drizzle-zod. The latest stable (0.8.3) has no v1 release (only beta dist-tags), so the optional Drizzle-Zod validation path breaks on v1.

If you use neither transactions nor drizzle-zod, plain query building (select / insert / sql, all four drivers) is close — mostly type-annotation updates for the new config shape — but I'm not declaring support while the transactional and zod paths are broken.

Tracking it

#135 adds a non-blocking CI job that installs drizzle-orm@rc on every push and runs the suite, plus a support-policy section documenting exactly the above. It's an early-warning signal: when v1 leaves RC and the CLS adapter + drizzle-zod ship v1 builds, that job goes green and I'll widen the peer range and cut a release.

Timeline

Gated on Drizzle promoting v1 out of RC and those two peers shipping v1 support — not something I can pull forward from here. Until then, stay on 0.45.x.

Leaving this open to track v1 landing.

[rodrigobnogueira]

Update: 0.4.0 is out and makes this work today.

The peer range now admits the v1 line: >=0.30.0 <2.0.0 || >=1.0.0-rc.1 <2.0.0. The subtlety: plain semver ranges never match prereleases, so <2.0.0 alone still rejected 1.0.0-rc.4 — with the explicit RC comparator, npm install @nest-native/drizzle drizzle-orm@rc resolves cleanly, no --legacy-peer-deps.

The CI canary now runs the full suite against drizzle-orm@rc and is green on 1.0.0-rc.4: module wiring, DI, repositories, testing helpers, plain query building on all four drivers — and a real commit/rollback through the CLS transactional adapter.

Two things remain upstream: @nestjs-cls/transactional-adapter-drizzle-orm still peer-pins ^0 (override recipe in the support policy; fix proposed in Papooch/nestjs-cls#604), and drizzle-zod has no v1 build yet. Keeping this open until v1 GA and those land.

[rodrigobnogueira]

One correction to my last comment: the drizzle-zod gap doesn't exist — on the v1 line, Drizzle-Zod moved into drizzle-orm as the drizzle-orm/zod subpath (zod is an optional peer of drizzle-orm there; /valibot, /typebox, /arktype moved the same way). The standalone drizzle-zod package stays on 0.x, so the migration is one import: 'drizzle-zod' → 'drizzle-orm/zod'.

Verified against 1.0.0-rc.4 — schema derivation and parsing work — and the RC canary now smokes that path on every push (spec, merged in #138). Support policy corrected.

So the only remaining v1 gate is the CLS adapter's ^0 pin — fix proposed in Papooch/nestjs-cls#604.