QueryNameVariables type enforces runtime scalars to be present in the return value when they are not required

[gwennlbh]

Describe the bug

Currently, the (query name)Variables type, exported from ./$houdini, requires the return type to contain values for variables that are defined with runtime scalars, even though not defining them works.

For example, take the following query document, with FooScalar a runtime scalar:

query Example($a: FooScalar!, $b: String!, $c: Boolean) {
   foo, bar
}

In a +page.ts file:

import { type ExampleVariables } from './$houdini';

//                                                        v~~ Missing property "a" in return type
export const _ExampleVariables: ExampleVariables = async () => ({ b: "spam", b: true })

Workaround

We are currently hardcoding a list of runtime scalars (we juste have one for the moment), and re-defining the type using VariablesFunction:

https://github.com/inp-net/churros/blob/c801d54925f5f056f37a302b0dd4f40600d9b6e5/packages/app/src/lib/typing.ts#L16-L24

...and using them accordingly:

https://github.com/inp-net/churros/blob/c801d54925f5f056f37a302b0dd4f40600d9b6e5/packages/app/src/routes/(app)/%2Blayout.ts#L7

I'll set up a repro link later if it's necessary.

Since runtime scalars are a gated feature, I guess this could be expected, but accomodating for this would lead to a better DX. I may have time to work up a PR sometime around the end of next week

Reproduction

No response

[AlecAivazis]

Ah! nice catch. Thanks for reporting it. I definitely agree we should tidy this up a bit. We have all of the information we need to know if the user has enabeld the feature so I think this would be a great improvement.