[BUG]: recursive JSON schema objects generate strange duplicate types

[fstanis]

Issue Type

Quicktype's output when given a JSON schema for a recursive object (for example, a tree node) includes additional output where the type that's recursive is duplicated, which can result in huge redundant outputs.

Context (Environment, Version, Language)

Input Format: JSON schema Output Language: C# and TypeScript tested, but seems to be present in all of them

app.quicktype.io

Description

I have a type that represents a tree node which I have a JSON schema for using $ref. However when Quicktype generated C# code, it ended up generating significant amounts of redundant code - because the tree node contains many complex types in the "data" field, all of these types ended up being duplicated with prefixes such as "Fluffy" or "Purple".

Input Data

This is a minimal example of a tree node with just an ID:

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "$id": "T2",
  "type": "object",
  "properties": {
    "data": {
      "type": "object",
      "properties": {
        "id": {
          "type": "string"
        }
      }
    },
    "children": {
      "type": "array",
      "items": {
        "$ref": "T2"
      }
    }
  }
}

Expected Behaviour / Output

C#

public partial class Tree
{
    public Tree[] Children { get; set; }
    public TreeData Data { get; set; }
}

public partial class TreeData
{
    public string Id { get; set; }
}

TypeScript

export interface Tree {
    children?: Tree[];
    data?:     TreeData;
}

export interface TreeData {
    id?: string;
}

Current Behaviour / Output

C#

public partial class Tree
{
    public Tre[] Children { get; set; }
    public TreeData Data { get; set; }
}

public partial class Tre
{
    public Tre[] Children { get; set; }
    public ChildData Data { get; set; }
}

public partial class ChildData
{
    public string Id { get; set; }
}

public partial class TreeData
{
    public string Id { get; set; }
}

TypeScript

export interface Tree {
    children?: Tre[];
    data?:     TreeData;
    [property: string]: any;
}

export interface Tre {
    children?: Tre[];
    data?:     ChildData;
    [property: string]: any;
}

export interface ChildData {
    id?: string;
    [property: string]: any;
}

export interface TreeData {
    id?: string;
    [property: string]: any;
}

[yeikel]

@jeffwidman From what I can tell, you are the main author of the python docker build. What do you think of this take?

[yeikel]

For clarity, I am not expecting the team to tackle this right now given the known capacity challenges. I can give it a go provided we agree that it is a good idea.

[jeffwidman]

LOL, I filed pretty much this exact ticket on our internal issue tracker yesterday morning. So I clearly think it's a good idea.

We generally want to avoid tight coupling between ecosystems so I don't know if there should be a single parent docker image that both inherit from, or if uv should inherit from python... I don't know the solution, just that what we've got is a problem.

Additionally, the fact that the rust dockerfile is pretty much copy/pasted into both python and uv results in a bit of a mess as well.

As you alluded to, the business has me focused elsewhere lately, so I don't have the capacity to personally be too involved, but I'm sure the team focused on core would be happy to review if you want to give it a go. I do think it's a good idea. 👍

[markhallen]

@yeikel this was on my radar. If you want to raise a PR I will review it. Thanks

[yeikel]

Thanks @markhallen

I took a closer look and I have a few notes/questions:

1. It looks like the biggest challenge will be the native helpers. From what I can tell, we rebuild the helpers for each Python version, and the uv and python ecosystems use slightly different helper codebases. The differences are small, but they exist. This potentially means that unless we align these two, it won't be possible to avoid the two builds

https://github.com/dependabot/dependabot-core/blob/c093035965a062ab2d8f77a5c5e506c9b81b6cc0/uv/Dockerfile#L76

2. I’m not fully familiar with how the split was done, but it appears there’s still some leftover code from the python ecosystem inside uv. For example, my understanding is that uv and poetry aren’t directly related, yet there’s poetry-related code as well as a dependency on it within the uv ecosystem. Is that intentional?

https://github.com/dependabot/dependabot-core/blob/c093035965a062ab2d8f77a5c5e506c9b81b6cc0/uv/helpers/requirements.txt#L7

[yeikel]

I'll go ahead and assume that poetry is not needed in the uv ecosystem as the documentation states clearly that poetry support is under the pip ecosystem

@markhallen If you get a minute to confirm this, it'd help to accelerate any future review

[markhallen]

I'll go ahead and assume that poetry is not needed in the uv ecosystem as the documentation states clearly that poetry support is under the pip ecosystem

@markhallen If you get a minute to confirm this, it'd help to accelerate any future review

Yes. This was not included intentionally.