Adding apiVersion causing breaks in Sanity code

Hey everyone, glad to be in this slack!
We make heavy use of Sanity for work.

We have still been using the Sanity version without setting an apiVersion. So I added that and now I am getting some breaks in the code.

I haven't had much success finding out why adding an apiVersion would break current queries but maybe someone here has experienced this and could point me in the right direction?

Unless something's changed, the docs suggest that the absence of indicating an API version makes it assume a value of 'v1' which it also indicates was the first .
Because it's date-based, the only thing I can think of as far as a point of reference to when changes happened is using the
changelog and the filters on the side to see when relevant/breaking parts of your query changed and whatever might bring them back into alignment.

So the behavior that is happening right now is that without an apiVersion set the property is set to an array of objects
With an apiVersion set the property is sent back as null

Can you show your query?

As Vincent mentioned, omitting the apiVersion will cause the client to use

v1

of the API. You should be able to specify

apiVersion: 1

when configuring to remove the warning, but eventually will want to migrate to a later version as there have been several improvements. Kitty’s suggestion to post the query would be a big help, but if you're using `@`/`^` those have changed behaviours between

v1

and later.

I apologize for not responding sooner. I spoke to work and they didn't want me to share the query since it is business logic related.
However, after seeing
's response, I am wondering if I am setting the apiVersion correctly.
Is the apiVersion supposed to be a date? Or is it an actual version? I was under the impression that it was a date string. But reading above makes it seem like it could be v1 v2.02....something like that.

If we’re talking about configuring the JS client to use an API version, the version will either be

1

or a date >=

2021-03-25

. There’s no

v2.02

, etc., and I believe the

v

is optional. More details are here .
Using the HTTP API, the same rules apply but the

v

is mandatory.

idk the best way to ask this but I guess my simple question is, will version 1 of the api be deprecated in the future?
Or is there a plan for longterm support for certain older versions?

Thanks!

There’s no plan I’m aware of to deprecate

v1

soon. That said, it won’t have new features added to it, so there may come a point when it’s not possible to run

v1

with the Studio release of the time. When it is deprecated, it will be done in accordance with the process we’ve laid out .

Our approach has always been to make as few breaking changes as possible, and when we have to do so, to put plenty of thought and consultation into it.

v1

remains the “default” in the client and many people and customers still use it.

Thanks! I was trying to migrate everything for work over to a updated apiVersion and I think I am going to go a slower route. We use Zod for validation on what is returned from Sanity so Im gonna start there an then have validation set up so that when we start moving to a newer version it is much less of tons of changes.
The biggest thing I was running into was what gets ignored or is undefined in v1 is now null in newer versions.

Sounds good! The `null`/`undefined` issue you mentioned is being considered internally. I don’t know its status but it’s certainly on our radar .

There are workarounds if you’re interested, but it involves a conditional check on every field (if I recall correctly) so probably more work than it’s worth.
Edit: The check is

defined(field) => {field}

in your GROQ query.