feat: require project ID for project-level fetchers

[judofyr]

Description

(Note: There should be no changes to the React package here.)

This changes the core functions for working with dataset/project to explicitly require a project ID and not look into the SanityInstance configuration. This is part of a future where we only have a single SanityInstance and instead every function can be invoked on arbitrary projectId/datasets without being configured explicitly.

What to review

Testing

Fun gif

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Review	Updated (UTC)
sdk-docs	Ready	Preview, Comment	Dec 15, 2025 0:31am
sdk-kitchensink-react	Ready	Preview, Comment	Dec 15, 2025 0:31am

[judofyr]

• feat: require project ID for project-level fetchers #631 👈 (View in Graphite)
• feat: make applyDocumentActions more similar to the rest #630 : 1 other dependent PR (#632 )
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[cngonzalez]

Less sure about this one because it's technically a breaking change. I'm unclear on how vital it is to make this change now

[cngonzalez]

How strongly do we feel about continuing checking the instance in this PR and come back to it later in a broader breaking change? There are plenty of other hooks that still use the instance at this point in the stack, and this will throw anyway with a configuration that's just a Media Library source (I think)

(I also think there are a number of issues that will crop up now if you try to make an SDK app with just a Media Library source)

[judofyr]

Yea, this came from me basically uncommenting the definition of instance.config.projectId and trying to get rid of them. I think we can workaround this even with a new "named sources" concept by basically having a helper function like this:

function getProjectId(sources) {
  // Prioritize default source:
  if ('projectId' in sources.default) return sources.default.projectId
  // Loop over all sources, find the projectId, if there's only one => return it
  // If there's multiple => Error
}

I can look into introducing this separately. I will close this and rather rebase the rest on top of latest main.