@sanity-typed/groq
Infer GROQ Result Types from GROQ strings
Page Contents
Install
npm install @sanity-typed/groq
Usage
Typically, this isn't used directly, but via @sanity-typed/client's and @sanity-typed/groq-js's methods that use groq strings. But it can be done directly:
import { ExecuteQuery, RootScope } from "@sanity-typed/groq";
type Foo = ExecuteQuery<
'*[_type=="foo"]',
RootScope<
// If you have SanityValues from @sanity-typed/types, use those types:
// import { DocumentValues } from "@sanity-typed/types";
// DocumentValues<SanityValues>
({ _type: "bar" } | { _type: "foo" })[],
{ _type: "bar" } | { _type: "foo" }
>
>;
/**
* Foo === {
* _type: "foo";
* }[]
*/
There is also a Parse and Evaluate if you need the AST:
import { Evaluate, Parse, RootScope } from "@sanity-typed/groq";
type Tree = Parse<'*[_type=="foo"]'>;
/**
* Tree === {
* type: "Filter";
* base: { type: "Everything" };
* expr: {
* type: "OpCall";
* op: "==";
* left: { type: "AccessAttribute"; name: "_type" };
* right: { type: "Value"; value: "foo" };
* };
* }
*/
type Foo = Evaluate<
Tree,
RootScope<
// If you have SanityValues from @sanity-typed/types, use those types:
// import { DocumentValues } from "@sanity-typed/types";
// DocumentValues<SanityValues>
({ _type: "bar" } | { _type: "foo" })[],
{ _type: "bar" } | { _type: "foo" }
>
>;
/**
* Foo === {
* _type: "foo";
* }[]
*/
For either, you can pass in a full scope:
import { ExecuteQuery } from "@sanity-typed/groq";
type Foo = ExecuteQuery<
'*[_type=="foo"]',
{
context: {
client: ClientConfig;
dataset: ({ _type: "bar" } | { _type: "foo" })[];
delta:
| {
after: { _type: "bar" } | null;
before: { _type: "bar" } | null;
}
| {
after: { _type: "foo" } | null;
before: { _type: "foo" } | null;
};
identity: string;
parameters: { [param: string]: any };
};
parent: null;
this: null;
}
>;
Chances are, you don't need this package directly.
Considerations
The parsed tree changes in seemingly breaking ways
@sanity-typed/groq attempts to type its parsed types as close as possible to groq-js's parse function output. Any fixes to match it more correctly won't be considered a major change and, if groq-js changes it's output in a version update, we're likely to match it. If you're using the parsed tree's types directly, this might cause your code to break. We don't consider this a breaking change because the intent of these groq libraries is to match the types of a groq query as closely as possible.
Typescript Errors in IDEs
Often you'll run into an issue where you get typescript errors in your IDE but, when building workspace (either you studio or app using types), there are no errors. This only occurs because your IDE is using a different version of typescript than the one in your workspace. A few debugging steps:
VSCode
Type instantiation is excessively deep and possibly infinite
🚨 CHECK Typescript Errors in IDEs FIRST!!! ISSUES WILL GET CLOSED IMMEDIATELY!!! 🚨
You might run into the dreaded Type instantiation is excessively deep and possibly infinite error when writing GROQ queries. This isn't too uncommon with more complex GROQ queries. Unfortunately, this isn't a completely avoidable problem, as typescript has limits on complexity and parsing types from a string is an inherently complex problem. A set of steps for a workaround:
- While not ideal, use
@ts-expect-error to disable the error. You could use @ts-ignore instead, but ideally you'd like to remove the comment if a fix is released.
- You still likely want manual types. Intersect the returned type with whatever is missing as a patch.
- Create a PR in
groq/src/specific-issues.test.ts with your issue. #642 is a great example for this. Try to reduce your query and config as much as possible. The goal is a minimal reproduction.
- If a PR isn't possible, make an issue with the same content. ie, the query and config you're using. Again, reduce them as much as possible. And then, now that you've done all the work, move it into a PR instead!
- I'm one person and some of these issues are quite complex. Take a stab at fixing the bug! There's a ridiculous amount of tests so it's relatively safe to try things out.
People will sometimes create a repo with their issue. Please open a PR with a minimal test instead. Without a PR there will be no tests reflecting your issue and it may appear again in a regression. Forking a github repo to make a PR is a more welcome way to contribute to an open source library.
Breaking Changes
2 to 3
Typescript version from 5.7.2 <= x <= 5.7.3
The supported Typescript version is now 5.7.2 <= x <= 5.7.3. Older versions are no longer supported and newer versions will be added as we validate them.
1 to 2
Typescript version from 5.4.2 <= x <= 5.6.3
The supported Typescript version is now 5.4.2 <= x <= 5.6.3. Older versions are no longer supported and newer versions will be added as we validate them.
Alternatives
