graphql-scalars
A custom scalar should reject what can be judged from the value alone and pass everything else through to the resolver.
Where a scalar runs
A scalar's parse functions run before any resolver, and every resolver receives whatever they do not reject as valid. graphql-scalars, the shared library of custom scalars, takes no runtime dependencies. The maintainers declined one proposed for the ULID scalar and suggested copying the reference function instead. Four scalars were contributed under that constraint.
What each checks
- GeoJSON: an object or a JSON string; all seven geometry types plus Feature and FeatureCollection; positions of two or three numbers with longitude within ±180 and latitude within ±90; a LineString of at least two positions; a Polygon ring of at least four that ends where it starts; a bbox of four or six numbers.
- CountryName: a fixed list of 246 ISO 3166-1 English short names, matched case-sensitively after trimming.
- ULID: a regular expression requiring a first character of 0 to 7 and Crockford base32, matched case-insensitively and uppercased on output.
- Cuid2: a separate scalar from Cuid, format only.
What they leave out
- GeoJSON does not check winding order, self-intersection, whether a bbox matches its geometry, or crs. A polygon that crosses itself is valid GeoJSON at the schema boundary.
- CountryName rejects anything not on a list that is maintained by hand.
- Two corrections to the GeoJSON scalar, its codegen type and its mock values, are open upstream.
Validity that depends on the whole value
Shape validation at the scalar holds for values whose validity is a property of the string: an identifier format, a coordinate range. Where validity depends on the whole value (a polygon's geometry) or on a list that changes with the standard, the scalar either takes a dependency the library refuses or passes the value on. A resolver that consumes a GeoJSON polygon checks its geometry itself.