Zod 4 support

[scottrippey]

Zod 4 was recently released, and includes a number of great improvements. Most notably, the "Type instantiation is excessively deep and possibly infinite" issues have been resolved, which is a problem that has been frequently reported with GroqD.

Below, we can discuss the paths needed for GroqD to fully support Zod 4.

Considerations

• Compatibility with Zod 4 - we need to ensure the library is fully compatible with Zod 4. We need tests.
• Removing dependency on Zod 3 - we need to discuss how to best remove the (optional) dependency on Zod 3.

[scottrippey]

Compatibility with Zod 4

GroqD >=1.7 should already be compatible with Zod 4.
The core library has NO dependencies on Zod 3, and does NOT import any types from Zod 3. Since Zod 4's .parse function is pretty much the same as Zod 3, GroqD should be able to use Zod 4.

However, this needs to be verified and tested, and the documentation needs to be updated to reflect this.

[scottrippey]

Preparation checklist:

• Add unit tests
• Update documentation

[scottrippey]

Removing dependencies on Zod 3

With GroqD 1.x, the main export is createGroqBuilderLite which is completely decoupled from Zod.
However, to simplify the migration from [email protected] to 1.x, we also export createGroqBuilderWithZod, which reexports a handful of Zod (v3) methods.

This was so we could continue supporting the q.string() syntax. However, this syntax was deprecated, and all examples/docs have been rewritten to use z.string() syntax.

Considerations for decoupling from Zod 3:

• The Zod dependency is exported from the root package, like import { createGroqBuilderWithZod } from "groqd". Hopefully a bundler will tree-shake the entire Zod dependency if you didn't use this import, but that's not easily guaranteed.
• Zod 3 is currently listed as a dependency for the package, so it gets installed even if you don't use it
• We do have a few utilities like q.default(...) and q.slug(...) which are designed to work with Zod; if we eliminate Zod completely, should we eliminate these methods?

[scottrippey]

I propose that we drop Zod as a dependency altogether.

• Should be a major version jump, eg. 2.0
• Drop the Zod utils -- except maybe keep some variation of q.default or .nullToUndefined()