Type alias circularly references itself #14174

pelotom · 2017-02-19T08:37:27Z

Why does this work:

type Foo = { x: Foo }

but this doesn't:

type Bar<A> = { x: A }
type Foo = Bar<Foo>
//   ^^^ Type alias 'Foo' circularly references itself

Shouldn't they be equivalent?

KiaraGrouwstra · 2017-06-12T09:35:23Z

See the explanation here for more info.

RyanCavanaugh · 2017-06-12T18:13:57Z

type Foo = Bar<Foo>

Illegal because we don't know that the definition of Bar isn't

type Bar<T> = T;

pelotom · 2017-06-12T19:11:50Z

Don't you have access to the definition of Bar so you could check that?

RyanCavanaugh · 2017-06-12T19:19:51Z

Bar might be

type Bar<T> = Foo<T>;

and now we're going infinitely deep.

Type aliases and interfaces are subtly different and there are rules about self-recursion for aliases that don't apply to interfaces. Because an alias is supposed to always be "immediately expandable" (it's as if it were an in-place expansion of its referand), there are things you can do interfaces you can't do with type aliases.

pelotom · 2017-06-12T19:53:30Z

Cycles can be detected and you can give up at that point, but as long as you can topologically order the type aliases by their references to one another it's fine. Haskell, PureScript, Scala etc have no problem with this.

RyanCavanaugh · 2017-06-12T21:17:58Z

I mean, we could, it's just that writing interface Bar<T> extends Foo<T> { } accomplishes the same thing without requiring us to rearchitect how type aliases work

pelotom · 2017-06-13T07:02:00Z

Sure, you can do that to emulate

type Foo = Bar<Foo>

But what about

type Foo = Bar<Foo> | Baz<Foo>

In this situation afaict the only solution is to expand the definitions of Bar and Baz into the union, substituting Foo for their type variable. Bar and Baz (and however many other alternatives) could be large complex interfaces, and must now each be maintained as 2 separate copies that must be kept in sync with one another.

skreborn · 2017-06-27T11:51:42Z

I'm trying to create a type that circularly references itself, but in a way that it makes sense - or at least it does to me. This is basically the same problem as @pelotom is having.

type Data = number | string | Data[] | Record<string, Data>;

If I modify it to the following, it works as intended, but this really is just more work for the user. This gets even worse when the data types are more complicated than a simple key-value pair.

type Data = number | string | { [key: number]: Data } | { [key: string]: Data };

This type allows me to create values like the following and handle them in a type safe way even when they are deeply nested.

const data: Data = {
    foo: [ 1, 'one', { two: 2 } ],
    bar: 'foobar'
};

@RyanCavanaugh Is there any other (sane) way to create type-safe nested objects?

mhegazy · 2017-08-17T18:37:09Z

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.

pelotom · 2017-08-17T18:43:35Z

I think this is a reasonable feature request for reasons that are made clear in the comments, can we reopen please?

brandonbloom · 2017-09-06T20:52:12Z

I think aleksey-bykov nailed the primary goal use case in this comment:
#6230 (comment)

type Json = null | string | number | boolean | Json[] | { [name: string]: Json }

zpdDG4gta8XKpMCd · 2017-09-07T23:11:46Z

please stop bringing this silly "going infinitely deep" excuse, will you? we are all mature developers to know how to deal with it, aren't we?

zpdDG4gta8XKpMCd · 2017-09-07T23:15:36Z

@brandonbloom the json problem was solved without recursive types, was posted somewhere in the issues

RyanCavanaugh · 2017-09-07T23:21:15Z

please stop bringing this silly "going infinitely deep" excuse, will you? we are all mature developers to know how to deal with it, aren't we?

Definitely 😆

zpdDG4gta8XKpMCd · 2017-09-07T23:29:28Z

come on, if you know you going deep you can prevent it, if you dont then you will see those overflows and thrn you know, it is not a stopper by any means or not an excuse

moreover if a problem is so bad maybe it makse sense to add some static checks to see where tge problem is likely to arise?

and why are so few new features to typescript been made lately, are you guys on a cut budget?

RyanCavanaugh · 2017-09-07T23:46:11Z

Lots of summer vacations, some parental leave, slightly more staff turnover than usual, and mapped types had a substantial bug tail that's taken a lot of time.

pelotom · 2017-09-07T23:51:28Z

I appreciate the TypeScript team's hard work. Mapped types have been a great addition and well worth the added complexity and corner cases!

thorn0 · 2018-05-17T09:25:23Z

Is it the same issue? playground

// Error: Type alias 'DeepPartial' circularly references itself
type DeepPartial<T> = T extends Array<infer U>
  ? Array<DeepPartial<U>>
  : T extends ReadonlyArray<infer U>
    ? ReadonlyArray<DeepPartial<U>>
    : T extends Date
      ? T
      : { [P in keyof T]?: DeepPartial<T[P]> };

upd: found working DeepPartial here

donaldpipowitch · 2018-06-18T05:59:51Z

I also wonder if I hit this bug or if it is different (modified example from this Tweet):

type FormValue<T> = { value: T }; // potentially many more fields

type FormModel<T> =
    //T extends Array<infer U> ? { value: FormModel<U>[] } : // THIS WORKS
    T extends Array<infer U> ? FormValue<FormModel<U>[]> :   // THIS ERRORS
    T extends object ? FormValue<FormModelObject<T>> :
    FormValue<T>;

type FormModelObject<T> = {
    [key in keyof T]: FormModel<T[key]>;
};

const model: FormModel<{
    bar: string,
    baz: {
        foo: string
    },
    items: string[]
}> = {} as any;

model.value.bar.value.toLowerCase();
model.value.baz.value.foo.value.toLowerCase();
model.value.items.value.map(item => item.value.toLowerCase());

(Playground)

I wonder if there is a solution were I can re-use FormValue for the array-case instead of re-writing it...?

Update: Looks like I found a solution in the DeepPartial comment from above. See this new example. Works, but was hard to figure out.

babakness · 2018-09-12T17:18:07Z

@tycho01 The code quoted by @Aleksey-Bykov is brilliant and it works; but only the first time. If I change the value of one of the tuples being concatenated, TypeScript hangs.

Also adding this function to the bottom of the concat example will hang Typescript

declare function foo<A, B>(a: A[], b: B[]): Concat<A,B>

Example link:

bobvanderlinden · 2018-11-23T21:51:10Z

Hmm, I think I also ran into this issue when trying to implement a type that deeply removes | null and optionalField?s from GraphQL-like structures:

type GraphQLObject = { '__typename': string }
type DeepRequired<T> = NonNullable<
  T extends Array<infer TItem>
    ? Array<DeepRequired<TItem>>
    : T extends GraphQLObject
      ? Required<{ [TKey in keyof T]: DeepRequired<T[TKey]> }>
      : T
>

The hack mentioned earlier will not work for me (or I haven't figured it out yet), because I need to infer TItem.

skreborn · 2018-11-24T11:32:59Z

@bobvanderlinden Would the following satisfy your requirements?

type GraphQLObject = { '__typename': string }

type DeepRequired<T> = T extends GraphQLObject ?
    Required<{ [TKey in keyof T]: DeepRequiredObject<T[TKey]> }> :
    (T extends Array<infer TItem> ? DeepRequiredArray<TItem> : DeepRequiredObject<T>);

interface DeepRequiredArray<T> extends Array<DeepRequired<T>> {}

type DeepRequiredObject<T> = {
    readonly [K in keyof T]: DeepRequired<T[K]>;
}

It seems to be producing the correct result in a simple case, but I'm unsure if it works in all required scenarios as I haven't yet used GraphQL myself.

interface Result {
    data: {
        search: [
            {
                __typename: string,
                name: string | null
            }
        ]
    }
}

const result: DeepRequired<Result> = {
    data: {
        search: [
            {
                __typename: "Human",
                name: "Han Solo"
            },
            {
                __typename: "Human",
                name: "Leia Organa"
            },
            {
                __typename: "Starship",
                name: "TIE Advanced x1"
            }
        ]
    }
};

result.data.search[0].name; // string

The implementation is largely based on @nieltg's DeepImmutable.

bobvanderlinden · 2018-11-24T11:49:02Z

@skreborn Wow, thanks for that one 😁👍. It's still a bit confusing why this variant does work, but directly inlining DeepRequiredObject and DeepRequiredArray doesn't. Is such a solution considered a workaround for this issue? Or am I just doing something fundamentally wrong in my type definition?

skreborn · 2018-11-24T12:02:17Z

@bobvanderlinden This is, as far as I know, the only workaround for now. Inlining them doesn't work because circular referencing is not allowed. So why is it allowed if you put an extra step between the two? It's black magic that might have something to do with lazy evaluation, but it's definitely beyond my knowledge on the internal workings of the type system.

babakness · 2018-11-24T20:30:11Z

You can sort of induce lazy evaluation by using the following pattern

type DeepUnnest<P extends any[]> = {
  'more': P extends Array<infer U>
    ?  U extends any[]
       ? DeepUnnest<U>
       : never
    : never
  'end': P extends Array<infer U>
    ? U
    : never,
}[
  P extends Array<infer U>
   ? U extends any[]
     ? 'more'
     : 'end'
   : 'end'
]

Its ugly but it works avoiding circular reference problems.

pronebird · 2019-02-28T16:39:43Z

I found that cyclic references work very well with nested objects

class Node<T> {}

type ExtractType<T> =
    T extends SchemaNode<infer S>
        ? S extends { [name: string]: SchemaNode<infer _> } 
            ? { [K in keyof S]: ExtractType<S[K]> }
            : S extends Array<infer E> 
                ? any[]
                : S           
    : T;

But as soon as I add an Array into the mix and attempt to type it, the whole thing breaks, i.e:

class Node<T> {}

type ExtractType<T> =
    T extends SchemaNode<infer S>
        ? S extends { [name: string]: SchemaNode<infer _> } 
            ? { [K in keyof S]: ExtractType<S[K]> }
            : S extends Array<infer E> 
                ? Array<ExtractType<E>> 
                : S           
    : T;

Full source:

class SchemaNode<T> {
    constructor(private value: T) { }
    validate(): ExtractType<SchemaNode<T>> {
        return this.value as any; // [redacted]
    }
}

type ExtractType<T> =
    T extends SchemaNode<infer S>
        ? S extends { [name: string]: SchemaNode<infer _> } 
            ? { [K in keyof S]: ExtractType<S[K]> }
            : S extends Array<infer E> 
                ? Array<ExtractType<E>>
                : S           
    : T;

type AccountType = "retail" | "company";

const mySchema = new SchemaNode({
    account: new SchemaNode({
        token: new SchemaNode("john doe"),
        type: new SchemaNode<AccountType>("retail"),
        options: new SchemaNode({
            autoLogin: new SchemaNode(true)
        }),
        isActive: new SchemaNode(true),
    }),
    history: new SchemaNode([
        new SchemaNode("went to barber shop")
    ]),
    credits: new SchemaNode(1000)
});

const res = mySchema.validate();

(res.account.token as string);
(res.account.isActive as boolean);
(res.account.type as AccountType);
(res.account.options.autoLogin as boolean);
(res.history as string[]);
(res.credits as number);

flux627 · 2019-08-07T05:21:17Z

I think aleksey-bykov nailed the primary goal use case in this comment:
#6230 (comment)
type Json = null | string | number | boolean | Json[] | { [name: string]: Json }

Here's my work-around:

type JsonPrimitive = string | number | boolean | null
interface JsonMap { [member: string]: JsonPrimitive | JsonArray | JsonMap }
interface JsonArray extends Array<JsonPrimitive | JsonArray | JsonMap> {}
type Json = JsonPrimitive | JsonMap | JsonArray

kevinbeal · 2019-08-14T19:49:01Z

I wanted to do this:

type lineOfCode = [string, lineOfCode[], [string, void | number]];

But I had to do this workaround:

type _lineOfCode = [string, unknown, [string, void | number]];
interface ILineOfCode extends _lineOfCode {
	1: ILineOfCode[];
}

Maybe this will help someone else.

ahejlsberg · 2019-08-30T23:20:37Z

With #33050 the original example can now be written as:

interface Bar<A> { x: A }
type Foo = Bar<Foo>

amatiasq · 2021-06-08T14:22:26Z

type JsonPrimitive = string | number | boolean | null
interface JsonMap { [member: string]: JsonPrimitive | JsonArray | JsonMap }
interface JsonArray extends Array<JsonPrimitive | JsonArray | JsonMap> {}
type Json = JsonPrimitive | JsonMap | JsonArray

Maybe that worked in a previous version but I'm getting this:

RebeccaStevens · 2022-01-27T09:55:16Z

Is it possible to write a tuple type that repeats a pattern?

// [A] or [A, B, A] or [A, B, A, B, A] or [A, B, A, B, A, B, A] or ...
type PatternTuple<A, B> = [A] | [A, B, ...PatternTuple<A, B>];

zaydek · 2022-03-16T04:18:32Z

This is working fine for me so far. *crosses fingers*

type JSONValue =
  | null
  | boolean
  | number
  | string

type JSONArray =
  | JSONValue[]
  | JSONArray[]
  | JSONMap[]

// Use interface because type errors:
//
//   type JSONMap = Record<string, JSONValue | JSONArray | JSONMap>
//   -> Type alias 'JSONMap' circularly references itself. ts(2456)
//
interface JSONMap { [key: string]: | JSONValue | JSONArray | JSONMap }

gajus · 2023-03-27T03:19:13Z

@RebeccaStevens did you ever figure this out? I asked a related question:

https://stackoverflow.com/q/75851865/368691

RebeccaStevens · 2023-03-27T03:31:07Z

No. The best I came up with was:

export type Alternate<A, B> =
  | [A]
  | [A, B, A]
  | [A, B, A, B, A, ...Array<A | B>];

gajus · 2023-03-27T03:40:11Z

ah, I missed [] in my question/example.

type NodeSnapshot =
  | string
  | [string, Attributes, ...NodeSnapshot]

The above should have been:

type NodeSnapshot =
  | string
  | [string, Attributes, ...NodeSnapshot[]]

The circular reference error threw me off.

Maybe it would make sense to change the error to:

- Type alias 'PlaywrightNodeSnapshot' circularly references itself.
+ Type alias 'PlaywrightNodeSnapshot' circularly references itself. Did you mean to spread NodeSnapshot[]?

RyanCavanaugh added the Needs Investigation This issue needs a team member to investigate its status. label May 24, 2017

RyanCavanaugh added Question An issue which isn't directly actionable in code and removed Needs Investigation This issue needs a team member to investigate its status. labels Jun 12, 2017

mhegazy closed this as completed Aug 17, 2017

RyanCavanaugh added In Discussion Not yet reached consensus Suggestion An idea for TypeScript and removed Question An issue which isn't directly actionable in code labels Aug 17, 2017

RyanCavanaugh reopened this Aug 17, 2017

massimonewsuk mentioned this issue Feb 5, 2018

"type MyType = MyType" should not be allowed facebook/flow#5771

Closed

krryan mentioned this issue Apr 13, 2018

Circular recursive types in a mapped-type and conditional-type world #23400

Closed

kgtkr mentioned this issue Aug 7, 2018

proposal:rest infer #26246

Closed

4 tasks

DanielRosenwasser mentioned this issue Sep 14, 2018

Design Meeting Notes, 9/14/2018 #27102

Closed

benneq mentioned this issue Dec 18, 2018

Version 1.9.1 Typescript issue with generics immerjs/immer#272

Closed

ahejlsberg mentioned this issue Aug 30, 2019

Recursive type references #33050

Merged

ahejlsberg added Fix Available A PR has been opened for this issue and removed In Discussion Not yet reached consensus labels Aug 30, 2019

ahejlsberg closed this as completed in #33050 Sep 25, 2019

sinclairzx81 mentioned this issue May 4, 2020

Typebox JSONSchema definition / self-hosting sinclairzx81/typebox#20

Closed

justinemmanuelmercado mentioned this issue Jun 18, 2020

feature: subscriptions api ScaleLeap/amazon-mws-api-sdk#85

Merged

andykais mentioned this issue Jun 23, 2020

Please provide a json basic type #1897

Closed

israelKusayev mentioned this issue Oct 8, 2020

[Typescript] Use selectorFamily with an interface facebookexperimental/Recoil#629

Open

tqma113 mentioned this issue May 18, 2021

Type alias circularly references and Index signature is missing conflict farrow-js/farrow#76

Open

viceice mentioned this issue May 9, 2022

feat(npm): add detection for overrides block renovatebot/renovate#15351

Merged

6 tasks

ignatiusmb mentioned this issue May 12, 2022

fix: more reliable typing of JSONObject sveltejs/kit#4876

Closed

5 tasks

escritorio-gustavo mentioned this issue Feb 29, 2024

Bug: Type Parameters are not imported Aleph-Alpha/ts-rs#241

Merged

Type alias circularly references itself #14174

Type alias circularly references itself #14174

Comments

pelotom commented Feb 19, 2017

KiaraGrouwstra commented Jun 12, 2017

RyanCavanaugh commented Jun 12, 2017

pelotom commented Jun 12, 2017

RyanCavanaugh commented Jun 12, 2017

pelotom commented Jun 12, 2017

RyanCavanaugh commented Jun 12, 2017

pelotom commented Jun 13, 2017 • edited Loading

skreborn commented Jun 27, 2017 • edited Loading

mhegazy commented Aug 17, 2017

pelotom commented Aug 17, 2017

brandonbloom commented Sep 6, 2017

zpdDG4gta8XKpMCd commented Sep 7, 2017

zpdDG4gta8XKpMCd commented Sep 7, 2017

RyanCavanaugh commented Sep 7, 2017

zpdDG4gta8XKpMCd commented Sep 7, 2017

RyanCavanaugh commented Sep 7, 2017

pelotom commented Sep 7, 2017

thorn0 commented May 17, 2018 • edited Loading

donaldpipowitch commented Jun 18, 2018 • edited Loading

babakness commented Sep 12, 2018

bobvanderlinden commented Nov 23, 2018

skreborn commented Nov 24, 2018 • edited Loading

bobvanderlinden commented Nov 24, 2018

skreborn commented Nov 24, 2018

babakness commented Nov 24, 2018

pronebird commented Feb 28, 2019

flux627 commented Aug 7, 2019 • edited Loading

kevinbeal commented Aug 14, 2019

ahejlsberg commented Aug 30, 2019

amatiasq commented Jun 8, 2021

RebeccaStevens commented Jan 27, 2022

zaydek commented Mar 16, 2022

gajus commented Mar 27, 2023

RebeccaStevens commented Mar 27, 2023

gajus commented Mar 27, 2023

pelotom commented Jun 13, 2017 •

edited

Loading

skreborn commented Jun 27, 2017 •

edited

Loading

thorn0 commented May 17, 2018 •

edited

Loading

donaldpipowitch commented Jun 18, 2018 •

edited

Loading

skreborn commented Nov 24, 2018 •

edited

Loading

flux627 commented Aug 7, 2019 •

edited

Loading