Struggling to define a simple recursive type

[agladysh]

I am trying to define a recursive type, which can be boolean, number, string, or array of itself or record of itself. Basically, a subset of an JSON object:

type Value = boolean | number | string | { [k: string]: Value} | Value[];

This does not compile with Type instantiation is excessively deep and possibly infinite.ts(2589) later:

const $ = scope({
  primitive: 'boolean | number | string',
  record: {
    '[string]': 'value'
  },
  value: 'primitive | record | value[]'
}).export();

Full code:

import { ArkErrors, scope } from 'arktype';

type Value = boolean | number | string | { [k: string]: Value} | Value[];

const $ = scope({
  primitive: 'boolean | number | string',
  record: {
    '[string]': 'value'
  },
  value: 'primitive | record | value[]'
}).export();

const schema = $.value;

async function main() {
  const value = [ '42 '];

  //  const t: typeof schema.infer = [ '42' ]; // Fails to compile if value[] is removed above

  const result = schema(value);

  if (result instanceof ArkErrors) {
    console.error('FAIL:', result.summary);
  } else {
    console.log('PASS', result);
  }
}

main().catch((e: unknown) => {
  console.trace(e);
});

Observation: if I remove value[] from the definition, the runtime validation passes for arrays, but the inferred type in the TypeScript land, of course, would not work with arrays (Index signature for type 'string' is missing in type 'string[]'). (Technically, I think that the validation should fail as well, but that's beside my question.)

Anyway, please help me to find where I can read on how to define such a recursive type? An example of how to write a schema for JSON would be really nifty.

[ssalbdivad]

One note would be you can reuse your Value type with type.cast to get cleaner names in your inference:

type Value = boolean | number | string | { [k: string]: Value } | Value[]

const $ = scope({
	primitive: "boolean | number | string",
	record: {
		"[string]": "value"
	},
	value: "primitive | record | value[]" as type.cast<Value>
}).export()

Unfortunately, there's still a problem where we try to extract the output type and get stuck in a loop.

Perhaps related to some changes I made recently handling array intersections. Created this issue to track it:

#1138

[ssalbdivad]

Here's one potential workaround you can use to tell ArkType not to recurse into your JSON array type, although it could interface with e.g. extracting morphs out of some other types because of how broad Value[] is.

type Value = boolean | number | string | { [k: string]: Value } | Value[]

declare global {
	interface ArkEnv {
		prototypes(): Value[]
	}
}

If you were to also brand Value like Value[] & {[mySymbol]: "jsonArray"}, I think that would be safe.

[agladysh]

Well, right, thank you. That's actually why the Value was defined there originally (but then I was looking at some older answer here, which used something like Infer<>, which I did't find in the current exports :) )

But it is a bit frustrating, as I would prefer to be able to use arktype as the single source of truth here, and having to define the type twice kind of defeats the purpose.

Meanwhile, will try the workaround tomorrow and report back. Thanks again!

[ssalbdivad]

Yeah, I understand that would definitely be nice. It may work without that, but the inference just can't look as nice because I can't create names like Value externally.

Unfortunately it seems TS has a much harder time in this case detecting that it is trying to infer a cycle within that array reference than in an object.

[ssalbdivad]

Also, I do have a json type internally, so for that case in particular the best solution might just be for me to expose it as a keyword.

[agladysh]

Note that my type in this case is JSON-like, but not a JSON (it does not allow null, which is, arguably, important for my specific DX case).

So I originally looked for an example that would show how to validate JSON, to be expanded (or, rather, reduced) upon. IMHO, that would be an useful reference in general, more useful didactically than having a built-in JSON support exposed.

(And, BTW, I do not care for names much, at least in this specific case. All I need is for the "type" to work properly both in TypeScript, where I might assign "foreign" objects to a typeof something.infer variable, and in the actual data validation.)