hydrogen codegen silently ignores non-string (URL) schema pointer, falls back to bundled schema + broad glob

Describe the bug

shopify hydrogen codegen only recognizes a project in .graphqlrc.js as "the storefront project" (and reuses its documents/config) when project.schema is a string ending in storefront.schema.json. If schema is set to an object-style schema pointer (e.g. to point codegen at a live introspection endpoint instead of the schema bundled with the installed @shopify/hydrogen version), the match silently fails and the CLI falls back to its own hardcoded config: the bundled storefront.schema.json and an overly broad document glob (*!(*.d).{ts,tsx,js,jsx} across the whole app directory) that also sweeps in the customer-account project's documents. No warning or error is surfaced — codegen just runs against the wrong schema with the wrong document set.

This makes it impossible to point local codegen at a live store (to validate against a newer Storefront API version than whatever schema ships bundled with the currently-installed @shopify/hydrogen release) without also losing the intended document scoping.

Steps to reproduce

1. In a Hydrogen project, edit .graphqlrc.js's default (storefront) project to use a URL-based schema pointer instead of getSchema('storefront'), e.g.:

   schema: {
     [`https://${process.env.PUBLIC_STORE_DOMAIN}/api/${process.env.PUBLIC_STOREFRONT_API_VERSION}/graphql.json`]: {
       headers: {'X-Shopify-Storefront-Access-Token': process.env.PUBLIC_STOREFRONT_API_TOKEN},
     },
   },
   

2. Run pnpm codegen / shopify hydrogen codegen.

Expected behavior

Codegen validates the storefront project's documents against the live schema at the URL, scoped to the storefront project's own documents glob.

Actual behavior

Codegen silently falls back to the bundled storefront.schema.json (ignoring the configured live schema entirely) and to a broad default document glob that also includes the customer-account project's documents, producing a flood of unrelated validation errors and never actually using the configured schema.

Root cause

In the @shopify/cli hydrogen codegen orchestration (e.g. dist/chunk-NGLMZYS7.js in @shopify/cli@4.8.0), the function that matches a loaded graphql-config project against the storefront/customer-account schema only checks:

function Ai(e, t) {
  if (!t) return;
  let r = Ze(e);
  return Object.values(t.projects || {}).find(
    (o) => typeof o.schema == "string" && o.schema.endsWith(r)
  );
}

typeof o.schema == "string" excludes any object/URL-style schema pointer, so the match always fails for that case, and the code falls through to its own default generates config (bundled schema + broad glob) with no error surfaced to the user.

Why this matters

The schema bundled with a given @shopify/hydrogen release can lag behind the actual Storefront API version configured via PUBLIC_STOREFRONT_API_VERSION. Concrete example: Cart.discountApplications is documented as available on Storefront API 2026-07 (confirmed via live introspection and shopify.dev docs), but it's absent from the bundled storefront.schema.json in every published @shopify/hydrogen version up to and including 2026.10.0-preview.2. Without a working way to point codegen at a live schema, projects are stuck unable to validate documents against fields/types that exist on their actual configured API version.

Suggested fix

Either:

• Support a graphql-config schema pointer that isn't a plain string (URL object, array form, etc.) when matching the storefront/customer-account project, or
• At minimum, warn loudly instead of silently falling back when a project's schema doesn't match the expected bundled-file pattern, so this doesn't fail silently.

Environment

• @shopify/cli: 4.8.0
• @shopify/hydrogen: 2026.4.5
• @shopify/hydrogen-codegen: 0.3.3
• Node: (project pins node: ^22 || ^24)

Start in the Hydrogen codegen orchestration around the matching function shown from dist/chunk-NGLMZYS7.js in @shopify/cli@4.8.0, then reproduce with the URL-based schema pointer in .graphqlrc.js. Done means the storefront project keeps its configured schema and documents glob, or clearly warns when that configuration cannot be matched, instead of silently using the bundled schema and broad glob.