Litho – Zero-config GraphQL tooling for VS Code.

Integers & Floats

Float types can be automatically coerced from integer literals. For example, the following code uses int literal 4 as a default value for a float type, but this is still allowed.

type Query {
    multiply(lhs: Float, rhs: Float)
}

query calculator($lhs: Float = 4, $rhs: Float = 2) {
    multiply(lhs: $lhs, rhs: $hs) 
}

However, it is not allowed to pass concrete int types where floats are expected. Note that in the following example, variables $lhs and $rhs are both declared as Ints.

type Query {
    multiply(lhs: Float, rhs: Float)
}

query calculator($lhs: Int, $rhs: Int) {
    multiply(lhs: $lhs, rhs: $rhs)
}

Strings

🚧

String literals are always delimited by double quotes. GraphQL does not accept string literals with single quotes.

For multi-line string literals, Litho automatically removes the first and last newline, and removes indent from every line. For example, the code below defines two types with a field example that have identical documentation string literals.

type MultiLineExample {
    """
String literal.
"""
    example: Boolean!
}

type SingleLineExample {
    "String literal."
    example: Boolean!
}

Booleans

🚧

Internally, Litho defines booleans as enum Boolean { true false }, which simplifies type checking, auto-completion, etc. for us. However, it’s technically a scalar Boolean to adhere to the GraphQL spec.

IDs

Custom Scalars

You can also define your own scalars. For custom scalars, the serialization format of your scalar is not defined by your schema. Litho is still able to do type checking by statically comparing the name of the expected type of a scalar against the type of a variable or literal, but it won’t be able to check if literals successfully deserialize into a particular custom scalar type.

scalar BigInt

As such, your scalar may be coerced from any type of input literal. For example, the GraphQL document is still valid because Litho has no way of knowing if the provided literal correctly deserializes into a BigInt.

query Example($bigInt: BigInt = { foo: true }) { ... }

Like built-in scalars, you will not be able to use custom scalars in unions (i.e. union Something = BigInt will fail to compile).

🚧

The name of a scalar must not start with __ (these are reserved names) or Litho will emit an error.

Once defined, Litho will automatically include your custom scalar in every context where it can be used (i.e. both in input and output types, but not in unions).

Scalar Extensions

You can also add directives to an existing scalar by extending it. For example, the code below adds the @specifiedBy directive to a scalar.

extend scalar BigInt @specifiedBy(url: "https://specs.litho.dev/BigInt.scalar")

Common Errors

E0029 Scalar type definition must have a name.

This is a syntax error that is emitted when Litho tried to parse a scalar definition but it didn’t find a name.

E0030 Scalar type extension must have a name.

This is a syntax error that is emitted when Litho tried to parse a scalar type extension but it didn’t find the name of the type that you want to extend.

E0031 Scalar type extension must have one or more directives.

This is a syntax error that is emitted when your scalar type extension is missing any directives (rendering the extension useless). For example, the code below extends scalar Example, but since it’s not adding any directives, the extension is pretty useless and the compiler is required to emit an error.

scalar Example
extend scalar Example