Allow setting per-schema scalar overrides explicitly via SchemaConfig

[tmoitie]

Fixes the silent loss of lazy type loading introduced with per-schema scalar overrides (#1869, v15.31.0), by allowing overrides to be set explicitly on SchemaConfig so the discovery scan of types can be skipped. Related to #1874.

The problem

The executor and validator resolve built-in scalars (Boolean, String, Int, Float, ID) via Schema::getType() on essentially every operation — including a bare { __typename }.

Since #1869 (and after #1884 moved scalar overrides exclusively to types), the first such lookup goes:

1. getType() calls loadType(), which returns null for built-in scalar names when a typeLoader is set (the TODO referencing After Upgrading from v15.30.2 => v15.31.0 Error: " {"exception":"[object] (GraphQL\\Error\\Error(code: 0): Config element \"String\" is not declared in GraphQL schema at " #1874).
2. getType() falls through to getScalarOverrides(), which calls materializeTypes() — fully resolving the types config to scan it for ScalarType instances shadowing built-in names.

When types is a lazy callable, that scan resolves it entirely. This silently turns the documented lazy schema pattern — typeLoader for per-name loading plus a lazy types callable for types not reachable from the root types — eager on the first executed query, for every schema, including the overwhelming majority that define no scalar overrides at all. The cost lives inside the user's callable, so the library cannot be lazy after invoking it; the only fix is to not invoke it on the hot path.

In PHP-FPM the Schema is rebuilt per request, so this is a per-request cost. Downstream impact observed in a Lighthouse (nuwave/lighthouse) app: every GraphQL operation became 1.5–3.4× slower wall-clock between 15.30.2 and 15.32.3 (~6× more PHP work, xdebug cachegrind 9.1 MB → 57 MB for an authed { __typename } request). Lighthouse's SchemaBuilder::build() is exactly this pattern:

$config->setTypeLoader(fn ($name) => $this->typeRegistry->search($name)); // lazy
$config->setTypes(fn (): array => $this->typeRegistry->possibleTypes());  // builds ALL types from the AST when invoked

Repro

$config = SchemaConfig::create()
    ->setQuery($query)
    ->setTypeLoader($lazyLoader)
    ->setTypes($countingCallableBuilding500Types);

$schema = new Schema($config);
$schema->getType('Boolean'); // per-request hot path

graphql-php	types materialised by one getType('Boolean')
v15.30.2	0 / 500
v15.31.0 … v15.32.3	500 / 500
this PR, default config	500 / 500 (unchanged)
this PR, scalarOverrides set (e.g. [])	0 / 500

The fix

Overrides cannot be discovered from a lazy types callable without resolving it — that is fundamental. So this PR makes explicitness possible instead: a new SchemaConfig option scalarOverrides.

• null (default): discover by scanning types, exactly as before — zero behaviour change for existing users.
• An array (including [] for "none"): use exactly these overrides, never scan. Explicit overrides take precedence in getTypeMap() the same way discovered ones do.

$schema = new Schema([
    'query' => $queryType,
    'typeLoader' => $myTypeLoader,
    'types' => $myLazyTypes,
    'scalarOverrides' => [$uppercaseString], // or [] for none
]);

The setter validates entries are ScalarType instances named after built-in scalars.

This gives lazy-schema users a one-line opt-out while keeping the scalar-overrides feature fully intact. If this lands, Lighthouse's SchemaBuilder::build() could pass its known overrides (usually []) explicitly and restore its pre-15.31 per-request performance — happy to file the companion PR there.

Downstream context: we currently pin 15.30.2 to avoid the regression, which re-exposes GHSA-r7cg-qjjm-xhqq, GHSA-fc86-6rv6-2jpm and the 15.31.5 quadratic-validation fix — this change is what would let us (and others in the same spot) unpin.

🤖 Generated with Claude Code