Incorporating a separate generic for the return type, which also extends JsonValue, resolves any type compatibility issues and allows for inferring a more specific return type:
function wrap <A extends JsonValue[], T extends JsonValue>(
fn: (...args: A) => T,
...args: A
): T {
return fn(...args);
}
const result = wrap(bar, { name: 'FOO', fooProp: 'hello'}); // okay 👍
//^? const result: Foo
Regarding the JsonValue type you presented: for the union member with string keys and JsonValue values (object type), it is more accurate to include undefined in a union with JsonValue. This makes the keys effectively optional, as there will not always be a value at every key in an object. The resulting value from accessing a non-existent key on an object is undefined at runtime:
type JsonValue =
| string
| number
| boolean
| null
| JsonValue[]
| { [key: string]: JsonValue | undefined };
// ^^^^^^^^^^^
This approach aligns with the serialization and deserialization algorithms of the JSON object in JavaScript, where properties with undefined values are not serialized. Since JSON does not support undefined as a type, undefined never exists in a deserialized value.
This type is both practical (allowing dot notation property access for any property name) and safe (requiring each value to be narrowed to JsonValue before using it).
Full code in TS Playground
Response update to your comment:
The playground answer still relies on interface Foo being a type. I require it to be an interface. Is this feasible?
It is feasible only if the interface extends (is limited by) the object-like union member of JsonValue.
The TS handbook section Differences Between Type Aliases and Interfaces emphasizes this point:
Type aliases and interfaces are quite similar, with the main difference being that a type cannot be extended to add new properties, unlike an interface which can always be extended.
This means that a type alias is finalized where it's defined, while an interface's exact shape is determined during type-checking because it can be altered elsewhere. To restrict changes to an interface, constraints must be applied:
An example using an unconstrained interface showcases a compiler error:
interface Foo {
name: 'FOO';
fooProp: string;
}
const bar = (foo: Foo) => foo;
const result = wrap(bar, { name: 'FOO', fooProp: 'hello'}); /*
~~~
Argument of type '(foo: Foo) => Foo' is not assignable to parameter of type '(...args: JsonValue[]) => JsonValue'.
Types of parameters 'foo' and 'args' are incompatible.
Type 'JsonValue' is not assignable to type 'Foo'.
Type 'null' is not assignable to type 'Foo1'.(2345) */
However, if the interface is confined to ensure compatibility with the object-like union member of JsonValue, no potential type conflicts arise:
type JsonObject = { [key: string]: JsonValue | undefined };
interface Foo extends JsonObject {
name: 'FOO';
fooProp: string;
}
const bar = (foo: Foo) => foo;
const result = wrap(bar, { name: 'FOO', fooProp: 'hello'}); // okay 👍
Code in TS Playground
For further information, refer to utility types in the TS handbook