🚨 You need to enable Continuous Integration on Greenkeeper branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet. We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please click the 'fix repo' button on account.greenkeeper.io.

I get the an undefined error trying to parse MyType.

import { View, ViewStyle, StyleProp } from 'react-native';
export type MyType = StyleProp<ViewStyle>

TypeError: Cannot read property 'getId' of undefined
    at ReferenceType.getId (/Users/awinograd/programming/ts-json-schema-generator/dist/src/Type/ReferenceType.js:12:26)                                                                                    
    at (.types.map (/Users/awinograd/programming/ts-json-schema-generator/dist/src/Type/UnionType.js:11:25)                                                                                                
    at Array.map (<anonymous>)
    at UnionType.getId (/Users/awinograd/programming/ts-json-schema-generator/dist/src/Type/UnionType.js:10:33)                                                                                            
    at ids.join.<.context.getArguments.map (/Users/awinograd/programming/ts-json-schema-generator/dist/src/CircularReferenceNodeParser.js:33:78)                                                           
    at Array.map (<anonymous>)
    at CircularReferenceNodeParser.createCacheKey (/Users/awinograd/programming/ts-json-schema-generator/dist/src/CircularReferenceNodeParser.js:33:61)                                                    
    at CircularReferenceNodeParser.createType (/Users/awinograd/programming/ts-json-schema-generator/dist/src/CircularReferenceNodeParser.js:13:26)                                                        
    at ChainNodeParser.createType (/Users/awinograd/programming/ts-json-schema-generator/dist/src/ChainNodeParser.js:17:50)                                                                                
    at ExpressionWithTypeArgumentsNodeParser.createType (/Users/awinograd/programming/ts-json-schema-generator/dist/src/NodeParser/ExpressionWithTypeArgumentsNodeParser.js:23:41) 

So far, I've figured out that getId is called in createType before the returned value is actually set on the reference on the same line in CircularReferenceNodeParser

We are starting to use unknown instead of any in some of our types.
Do you think it makes sense to add support for it? Should it be treated the same as any?
Should the any-related classes be updated to also recognize the unknown keyword or should it have new separate implementation classes?

Thanks

See vega/vega-lite#4850 (comment)

xiag-ag/typescript-to-json-schema has had some new features that we should port over. Your help is greatly appreciated.

See master...xiag-ag:master for a diff.

The dist directory is missing in the published version.

Looking for something similar to uniqueNames from YousefED/typescript-json-schema#151 though perhaps that is out of the scope of this project.

Please let me know if i'm missing anything. Thanks!

The devDependency ts-node was updated from 8.0.2 to 8.0.3.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

ts-node is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

See https://github.com/vega/vega-embed as an example. TSLint is deprecated so we should switch.

Hi! Great library here. We are heavily experimenting with using json schemas generated from our TypeScript interfaces on both front end and back end and this is obviously the glue that's holding it all together! With that said, there are some scenarios we are encountering that we are having to work around to get our schemas generated the way we want to, the main issues being around Mapped Types.

Consider the following interfaces:

export interface ISortableProperties {
    /**
     * @description id
     */
    id: number;

    /**
     * @description name
     */
    name: string;

    /**
     * @description date
     */
    date: Date;
}

export interface IResponse {
    unsortableProperty: string;
}

export interface IRequest {
    sortBy: Sortify<Pick<ISortableProperties, "id">> | Sortify<Pick<ISortableProperties, "name">> | Sortify<Pick<ISortableProperties, "date">>
}

export type Sortify<T> = {
    [P in keyof T]: sorting.SortDirection
}

The schema I'd like to see from this is

{
  "$schema": "http://json-schema.org/draft-06/schema#",
  "additionalProperties": false,
  "definitions": {
    "sorting.SortDirection": {
      "enum": [
        "ASC",
        "DESC"
      ],
      "type": "string"
    }
  },
  "properties": {
    "sortBy": {
      "anyOf": [
        {
          "additionalProperties": false,
          "properties": {
            "id": {
              "$ref": "#/definitions/sorting.SortDirection",
              "description": "id"
            }
          },
          "required": [
            "id"
          ],
          "type": "object"
        },
        {
          "additionalProperties": false,
          "properties": {
            "name": {
              "$ref": "#/definitions/sorting.SortDirection",
              "description": "name"              
            }
          },
          "required": [
            "name"
          ],
          "type": "object"
        },
        {
          "additionalProperties": false,
          "properties": {
            "date": {
              "$ref": "#/definitions/sorting.SortDirection",
              "description": "date"              
            }
          },
          "required": [
            "date"
          ],
          "type": "object"
        }
      ]
    }
  },
  "required": [
    "sortBy"
  ],
  "type": "object"
}

But I actually get the error :
ts-json-schema-generator\dist\ts-json-schema-generator.js:30
throw error;
^

TypeError: Cannot read property 'reduce' of undefined.

Is there any possibility of supporting this kind of scenario?

Thanks!
Rob

In Vega-Lite, MarkPropFieldDef's bin property should not support "binned" as its value. However, the generated JSON schema includes "binned".

From vega/vega-lite#4440 (comment):

export type TopLevelFacetedUnitSpec = TopLevel<FacetedExtendedUnitSpec> & DataMixins;`

TopLevel<S extends BaseSpec> = S &
  TopLevelProperties & {
...
}

export type FacetedExtendedUnitSpec = ExtendedUnitSpec<FacetMapping<Field>>;

export type ExtendedUnitSpec<
  /** Extra Encoding */
  EE = EmptyObject
> = NormalizedUnitSpec<EE> | CompositeUnitSpec<EE>;

See json-schema-org/json-schema-spec#258 and vega/vega-lite#3240 (comment)

Not sure if this belongs in the vega fork or the original repo.
Looking at the code, it's not clear that 'additionalProperties' can ever be set to true in the generated schema.

Best I could figure was this function https://github.com/vega/typescript-to-json-schema/blob/master/src/NodeParser/InterfaceNodeParser.ts#L65 and it'll always return false.

There seem to be no test cases to the counter.

Would appreciate clarification and/or some idea of how to go about fixing this. Happy to submit a PR once given a scent to follow.

I believe this only requires minor changes in https://github.com/vega/ts-json-schema-generator/blob/master/src/TypeFormatter/EnumTypeFormatter.ts.

export interface MyObject {
    bar: "ok" | "fail" | "abort" | string;
}

produces

> [email protected] run /Users/domoritz/Developer/UW/ts-json-schema-generator
> ts-node ts-json-schema-generator.ts "--path" "test.ts" "--type" "MyObject"

{
  "$ref": "#/definitions/MyObject",
  "$schema": "http://json-schema.org/draft-04/schema#",
  "definitions": {
    "MyObject": {
      "additionalProperties": false,
      "properties": {
        "bar": {
          "anyOf": [
            {
              "enum": [
                "ok"
              ],
              "type": "string"
            },
            {
              "enum": [
                "fail"
              ],
              "type": "string"
            },
            {
              "enum": [
                "abort"
              ],
              "type": "string"
            },
            {
              "type": "string"
            }
          ]
        }
      },
      "required": [
        "bar"
      ],
      "type": "object"
    }
  }
}

The enums could be consolidated.

export interface A {a: string;}
export interface B extends A {b?: string;}

generates

{
  "$schema": "http://json-schema.org/draft-04/schema#",
  "definitions": {
    "B": {
      "allOf": [
        {
          "type": "object",
          "properties": {
            "b": {
              "type": "string"
            }
          },
          "required": [],
          "additionalProperties": false
        },
        {
          "$ref": "#/definitions/A"
        }
      ]
    },
    "A": {
      "type": "object",
      "properties": {
        "a": {
          "type": "string"
        }
      },
      "required": [
        "a"
      ],
      "additionalProperties": false
    }
  },
  "$ref": "#/definitions/B"
}

The following object type checks correctly with TypeScript. However, it does not validate against the JSON schema. This is because B uses an allOf where each branch has additionalProperties: false (i.e., it fails the first branch).

const foobar:B = {a: 'foo'};

I believe ts2json should be consolidating these definitions together. Note: Switching allOf to anyOf doesn't yield a correct schema either ({b: 'foo'} correctly validates for instance).

Because of YousefED/typescript-json-schema#173 I'm currently trying to migrate to ts-json-schema-generator. The first problem I have with the new tool is missing support for conditional type nodes which worked fine with the typescript-json-schema tool. Here is a minimal example:

export type TypeName<T> =
    T extends string ? "string" :
    T extends number ? "number" :
    T extends boolean ? "boolean" :
    "object";

export type TestJSON = TypeName<string>;

When I try to generate the schema for TestJSON with this tool then I get this error message:

UnknownNodeError: Unknown node "TypeName<string>" (ts.SyntaxKind = 176)

I really like the clean structure of the new tool and it looks pretty straight forward how to implement this feature by adding a ConditionalTypeNodeParser class like this:

export class ConditionalTypeNodeParser implements SubNodeParser {
    public constructor(
        private typeChecker: ts.TypeChecker,
        private childNodeParser: NodeParser,
    ) {
    }

    public supportsNode(node: ts. ConditionalTypeNode): boolean {
        return node.kind === ts.SyntaxKind.ConditionalType;
    }

    public createType(node: ts.ConditionalTypeNode, context: Context): BaseType {
        ... magic here ...
    }
}

But unfortunately I lack the skills to implement the createType method. In theory the method has to check if node.checkType is assignable to node.extendsType and then returns node.trueType or node.falseType. But I don't know if this assignability check must be written from scratch here or if TypeScript already exposes some functionality to do this. And it gets more complicated if the check type is a union type so TypeName<string | Date> is resolved to "string" | "object" in this example.

I am scratching my head about this crash for more then a few minutes now. Unfortunately I have no idea how to resolve this, but I have at least a source file that triggers the problem. The crash seems to be related to a rather complicated type I have:

// Resolves a value at runtime. The value must be the name of a parameter
// that has been formally introduced before.
export interface ParameterReference {
  "$ref": string
}

// Allows properties of an object to be optional and to be
// a reference that can be resolved to an actual value later.
export type ParameterReferenceable<T> = {
  [P in keyof T]?: T[P] | ParameterReference;
}

// Type can be generated without problems
export interface TestInterface {
  myStr: string;
  myNum: number;
}

// Crashes with stacktrace below
export type RefTestInterface = ParameterReferenceable<TestInterface>;

I attempted to generate the schemas as follows, the second call ends in the mentioned stacktrace.

./node_modules/.bin/ts-json-schema-generator --path ./repro.ts --type TestInterface
./node_modules/.bin/ts-json-schema-generator --path ./repro.ts --type RefTestInterface

The exact stacktrace reads like this and seems to be in the function MappedTypeNodeParser.getProperties:

TypeError: Cannot read property 'reduce' of undefined
    at MappedTypeNodeParser.getProperties (/home/marcus/projects/scratch-sql/schema/json/node_modules/ts-json-schema-generator/dist/src/NodeParser/MappedTypeNodeParser.js:19:14)
    at MappedTypeNodeParser.createType (/home/marcus/projects/scratch-sql/schema/json/node_modules/ts-json-schema-generator/dist/src/NodeParser/MappedTypeNodeParser.js:14:92)
    at ChainNodeParser.createType (/home/marcus/projects/scratch-sql/schema/json/node_modules/ts-json-schema-generator/dist/src/ChainNodeParser.js:17:50)
    at TypeAliasNodeParser.createType (/home/marcus/projects/scratch-sql/schema/json/node_modules/ts-json-schema-generator/dist/src/NodeParser/TypeAliasNodeParser.js:20:94)
    at AnnotatedNodeParser.createType (/home/marcus/projects/scratch-sql/schema/json/node_modules/ts-json-schema-generator/dist/src/NodeParser/AnnotatedNodeParser.js:15:47)
    at ExposeNodeParser.createType (/home/marcus/projects/scratch-sql/schema/json/node_modules/ts-json-schema-generator/dist/src/ExposeNodeParser.js:14:45)
    at CircularReferenceNodeParser.createType (/home/marcus/projects/scratch-sql/schema/json/node_modules/ts-json-schema-generator/dist/src/CircularReferenceNodeParser.js:19:48)
    at ChainNodeParser.createType (/home/marcus/projects/scratch-sql/schema/json/node_modules/ts-json-schema-generator/dist/src/ChainNodeParser.js:17:50)
    at TypeReferenceNodeParser.createType (/home/marcus/projects/scratch-sql/schema/json/node_modules/ts-json-schema-generator/dist/src/NodeParser/TypeReferenceNodeParser.js:22:41)
    at ChainNodeParser.createType (/home/marcus/projects/scratch-sql/schema/json/node_modules/ts-json-schema-generator/dist/src/ChainNodeParser.js:17:50)

My versions:

> node --version                                                                                                                                                      
v10.7.0
> grep "ts-json-schema-generator" package-lock.json                                                                                                                    
      "resolved": "https://registry.npmjs.org/ts-json-schema-generator/-/ts-json-schema-generator-0.29.0.tgz",

Error:

UnknownNodeError: Unknown node "Exclude<ParameterType, ParameterType.Enum | ParameterType.Number>" (ts.SyntaxKind = 175)

Code:

enum ParameterType {
    Enum = "enum",
    Number = "number",
    String = "string",
    Date = "date"
    //...
}

interface IParameter {
    type: Exclude<ParameterType, ParameterType.Enum | ParameterType.Number>;
}

Just gave the project ago, but I'm seeing lots of errors like these:

/myproject/node_modules/@types/node/index.d.ts(390,48): error TS2304: Cannot find name 'Promise'.
/myproject/node_modules/@types/node/index.d.ts(392,62): error TS2304: Cannot find name 'Promise'.
/myproject/node_modules/@types/node/index.d.ts(505,50): error TS2304: Cannot find name 'Promise'.
/myproject/node_modules/@types/node/index.d.ts(507,65): error TS2304: Cannot find name 'Promise'.

Is there a way to override the included typescript libsdefinitions, or even better reuse the existing tsconfig.json?

Hey guys.

I'm trying to use a constant value as string literal types for an interface such as the following. Although it throws with the following output Cannot read property 'type' of undefined.

const FOO = 'foo';

interface Bar {
  value: typeof FOO;
};

I was wondering if you'd knew what might cause that. Or am I trying to use something that isn't supported by this library? Thanks!

@chrisrpatterson could you suggest a solution for this? I can't find a condition that says whether a commit is tagged or not. Right now I get errors because I already have a version published on NPM.

Hi! I 'm having some trouble with generating JSON schema for types with circular references. I would like to generate the schema for the following:

export type Tag = TagPrimitive | Tag[];
export type TagPrimitive = string | number | boolean | null;

However, as this isn't valid TypeScript, it is common to change it to the following:

export type Tag = TagPrimitive | TagArray;
export type TagPrimitive = string | number | boolean | null;
export interface TagArray extends Array<Tag> {}

This however results in the following error: Cannot read property 'getId' of undefined. So, the first version does generate the proper JSON schema, while the second is valid typescript. Is it possible to support the second method as well?

I'd like to better understand the intent of the three JsDoc modes: none/Basic/Extended.

Atleast for my purpose, I'd like them to behave like so:

• none: do not use JsDoc annotations (only use what the type system gives you?)
• basic: only use spec compliant annotations
• extended: allow non-standard annotations

But it seems this is not how things work.

Users/sanjay/Workspace/Repos/bridge-client/node_modules/types/node/index.d.ts(609,10): error TS2585: 'Symbol' only refers to a type, but is being used as a value here. Do you need to change your target library? Try changing the `lib` compiler option to es2015 or later.
Users/sanjay/Workspace/Repos/bridge-client/node_modules/@types/node/index.d.ts(815,38): error TS2583: Cannot find name 'Set'. Do you need to change your target library? Try changing the `lib` compiler option to es2015 or later.
Users/sanjay/Workspace/Repos/bridge-client/node_modules/@types/node/index.d.ts(2641,10): error TS2585: 'Symbol' only refers to a type, but is being used as a value here. Do you need to change your target library? Try changing the `lib` compiler option to es2015 or later.
Users/sanjay/Workspace/Repos/bridge-client/node_modules/@types/node/index.d.ts(6428,14): error TS2585: 'Symbol' only refers to a type, but is being used as a value here. Do you need to change your target library? Try changing the `lib` compiler option to es2015 or later.
Users/sanjay/Workspace/Repos/bridge-client/node_modules/@types/ws/index.d.ts(191,18): error TS2583: Cannot find name 'Set'. Do you need to change your target library? Try changing the `lib` compiler option to es2015 or later.
Users/sanjay/Workspace/Repos/bridge-client/node_modules/typescript/lib/lib.dom.d.ts(8546,11): error TS2300: Duplicate identifier 'Headers'.
Users/sanjay/Workspace/Repos/bridge-client/node_modules/typescript/lib/lib.dom.d.ts(8555,13): error TS2300: Duplicate identifier 'Headers'.
Users/sanjay/Workspace/Repos/bridge-client/src/generated/types.d.ts(3,6): error TS2300: Duplicate identifier 'Headers'.

I get these errors when trying to generate schema from a typings file. For reference:

• I have a type Headers defined in my typings file.
• I use Symbols as type parameters (e.g. type Id<T> = string and type UserId = Id<'User'>).
• I never use the type Set in my typings file.
• My tsconfig.json uses ES2018.

Any ideas how to fix this? Thanks!

When I try to run typescript-to-json-schema against the Legend union type defined here, I get a Maximum call stack size exceeded error. Each individual type within the union builds just fine, however.

Is there something about my type definitions I should be modifying/simplifying, or is this a bug with typescript-to-json-schema?

$ ./node_modules/.bin/typescript-to-json-schema --path typings/legend.ts --type Legend
/Users/arvind/Research/vega3/vega-parser/node_modules/typescript-to-json-schema/dist/typescript-to-json-schema.js:32
        throw error;
        ^

RangeError: Maximum call stack size exceeded
    at CircularReferenceTypeFormatter.getChildren (/Users/arvind/Research/vega3/vega-parser/node_modules/typescript-to-json-schema/dist/src/CircularReferenceTypeFormatter.js:26:23)
...

$ ./node_modules/.bin/typescript-to-json-schema --path typings/legend.ts --type SizeLegend
(executes correctly)

See YousefED/typescript-json-schema#156

See vega/vega-lite@b82b8ab in vega/vega-lite#1980

export interface Parent {
  a: A;
}
export type A = RealA;

export type RealA = { realA: string };

./node_modules/.bin/ts-json-schema-generator \
    --path 'test.ts' \
    --type 'Parent' \
    --expose 'export' \
    --jsDoc 'extended'

outputs

{
  "$ref": "#/definitions/Parent",
  "$schema": "http://json-schema.org/draft-06/schema#",
  "definitions": {
    "A": {
      "$ref": "#/definitions/RealA"
    },
    "Parent": {
      "additionalProperties": false,
      "properties": {
        "a": {
          "$ref": "#/definitions/A"
        }
      },
      "required": [
        "a"
      ],
      "type": "object"
    },
    "RealA": {
      "additionalProperties": false,
      "properties": {
        "realA": {
          "type": "string"
        }
      },
      "required": [
        "realA"
      ],
      "type": "object"
    }
  }
}

However, if RealA is not referred elsewhere, it's better to output:

{
  "$ref": "#/definitions/Parent",
  "$schema": "http://json-schema.org/draft-06/schema#",
  "definitions": {
    "A": {
      "additionalProperties": false,
      "properties": {
        "realA": {
          "type": "string"
        }
      },
      "required": [
        "realA"
      ],
      "type": "object"
    },
    "Parent": {
      "additionalProperties": false,
      "properties": {
        "a": {
          "$ref": "#/definitions/A"
        }
      },
      "required": [
        "a"
      ],
      "type": "object"
    }
    
  }
}

🚨 You need to enable Continuous Integration on Greenkeeper branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet. We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please click the 'fix repo' button on account.greenkeeper.io.

Hi,
when generating a schema for a tuple-like structure, I noticed some issues:

type Test = [number, number]

generates a schema that allows for additional values, while it shouldn't.

{
    "$schema": "http://json-schema.org/draft-06/schema#",
    "definitions": {
        "Test": {
            "type": "array",
            "items": [
                {
                    "type": "number"
                },
                {
                    "type": "number"
                }
            ],
            "minItems": 2,
            "additionalItems": {
                "anyOf": [
                    {
                        "type": "number"
                    },
                    {
                        "type": "number"
                    }
                ]
            }
        }
    },
    "$ref": "#/definitions/Test"
}

also,

type Test = [number, number, number|undefined]

requires at least three values, while it should require at least 2 and at most three.

Anyways, great project.

The devDependency @types/node was updated from 11.10.4 to 11.10.5.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@types/node is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

This is a discussion about the future of Typescript JSON schema generators.

TL;DR

• Use https://github.com/vega/ts-json-schema-generator/ if you want a robust but opinionated schema generator. It has good support for aliases and it continuously updated. This is probably the right option for most people.
• Use https://github.com/YousefED/typescript-json-schema if you want a less robust but hackable schema generator.

Trying to use this on a simple file: environment.token.ts:

export interface EnvConfig {
  production: boolean;
  apiEndpoint: string;
}

Getting an error when running:

$ ts-json-schema-generator --path src/app/core/environment.token.ts --type EnvConfig
/Sites/mysite/node_modules/@types/graphql/subscription/subscribe.d.ts(17,12): error TS2304: Cannot find name 'AsyncIterator'.
/Sites/mysite/node_modules/@types/graphql/subscription/subscribe.d.ts(29,12): error TS2304: Cannot find name 'AsyncIterable'.

My tsconfig.json looks like the following (from an Angular CLI project):

{
  "compileOnSave": false,
  "compilerOptions": {
    "paths": {
      "app/*": ["./app/*"]
    },
    "baseUrl": "./src",
    "outDir": "./dist/out-tsc",
    "sourceMap": true,
    "declaration": false,
    "module": "es2015",
    "moduleResolution": "node",
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "alwaysStrict": true,
    "noImplicitAny": true,
    "noImplicitThis": true,
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "target": "es5",
    "lib": [
      "es2017",
      "dom",
      "esnext.asynciterable"
    ],
    "plugins": [{
      "name": "@angular/language-service"
    }]
  }
}

It seems to be reading the whole project despite only giving it a single file

The devDependency @types/jest was updated from 24.0.1 to 24.0.2.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

@types/jest is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

Looking for a more up to date ts-json-schema generator since I've got a ton of errors from https://github.com/YousefED/typescript-json-schema most likely due to the TS version (though I'm not sure).

Would love to try this out, but need some examples for programmatic use to get started.

I'm building an API/client and using json schema to compare results from API with my TS interfaces during unit tests :)

Thanks!

This is a discussion. Please add your comments below.

I keep running into a wall when trying to use JSON schema with intersection types. I’d like to use anyOf but in combination with additionalProperties: false we end up with a schema that cannot be satisfied unless you only use properties that are defined in the intersection of the properties. So far, we have generated huge objects that merge properties but this is causing problems with intersections with unions (e.g. A & (B | C)). Going forward, I’d like to address this properly and see three options. 1) abandon JSON schema and use a more sophisticated schema enforcement 2) abandon additionalProperties: false, which means users won’t know if the mistype properties (this is what Vega does in some places), or 3) translate A & (B | C) to (A & B) | (A & C) and generate an anyOf of multiple large objects that are possibly largely the same. In the worse case, this can get exponentially larger. For example (A | B) & (C | D) = A & C | A & D | B & C | B & D Opinions?

See related issues: #62 and #4.

Another issue with JSON schema is inheritance, which cannot be expressed. So far we keep creating large objects for this case as well.

export type Condition<T> = {
  selection: LogicalOperand<string>;
} & T;

Condition<FieldDef|ValueDef> only has property selection but no properties from FieldDef and ValueDef.

See vega/vega-lite@06cc8dc in vega/vega-lite#1980.

Note that this is no longer a blocking issue since I redeclare this using Condition<FieldDef> | Condition<ValueDef> which is a better declaration anyway.

(I'm just filing the bug here so we are aware of this bug.)

The schema generator is super slow but it's not clear why. It takes more than a minute for Vega-Lite.

Hello,

I am investigating whether we could use this library to generate json schemas from our existing TypeScript interfaces. I have run into an issue with union types and type intersections. Is this a known limitation? In the provided example the "c" field is not present at all in the output.

input (test.ts):

interface A {
  x: boolean;
  c: 'b';
}
interface B {
  x: boolean;
  c: 'c';
}
export type D = (A|B) & {x: true};

ts-json-schema-generator --strictTuples --path 'test.ts' --expose 'export' --type D

output:

{
  "$ref": "#/definitions/D",
  "$schema": "http://json-schema.org/draft-06/schema#",
  "definitions": {
    "D": {
      "additionalProperties": false,
      "properties": {
        "x": {
          "enum": [
            true
          ],
          "type": "boolean"
        }
      },
      "required": [
        "x"
      ],
      "type": "object"
    }
  }
}

Thanks,
Kálmán

See vega/vega-lite#3183

cc @jakevdp

Hi, I'm working with a large TS codebase and I'm looking to optimize schema generation on file changes. So far, I've gotten SchemaGenerator hooked up to Typescript's incremental program watcher so ts.Program regenerations take ~20ms on file change.

Now, the bottleneck is SchemaGenerator.findRootNode(), which loops through every parsed file (including node_modules) looking for the type definition that matches the type name (taking about 600ms for us). I think we can speed this up by allowing the consumer to hint to SchemaGenerator which files to inspect first.

For example, if we know all of our exported types live in the ./types directory, we could tell SchemaGenerator to prioritize looking at files in the ./types directory. If the types we're looking to find don't exist, then continue looking at the rest of the files in the Program.

A few ideas:

• SchemaGenerator could take a fileComparator: (fileA: ts.SourceFIle, fileB: ts.SourceFile) => number function argument in its constructor that sorts the source files on init.
• SchemaGenerator could take a heuristic: (typeName: string, file: ts.SourceFile) => number function argument that scores files on whether the consumer thinks the type will exist there. SchemaGenerator would then look at high-scoring files first.

What do you think? If you like direction, I'm happy to open a PR

Based on a preliminary analysis, TypeScript 2.5 (RC) will break schema generation.

Specifically, it boils down to how we detect types that are exported:
https://github.com/vega/typescript-to-json-schema/blob/master/src/SchemaGenerator.ts#L65

[email protected]+ breaks this logic with this change:
microsoft/TypeScript@c6a6467

Would it be possible to get the JSON schema for the parameters of a function (or a method)?

For example:

export interface GetListInput {
    foo: string;
}

export function getList(input: GetListInput, input2: string) {
    // some code
}

I would get something like array:

{
  "$ref": "#/definitions/params",
  "$schema": "http://json-schema.org/draft-06/schema#",
  "definitions": {
    "GetListInput": {
      "additionalProperties": false,
      "properties": {
        "foo": {
          "type": "string"
        }
      },
      "required": [
        "foo"
      ],
      "type": "object"
    },
    "params": {
      "items": [
        {
          "$ref": "#/definitions/GetListInput"
        },
        {
          "type": "string"
        }
      ],
      "maxItems": 2,
      "minItems": 2,
      "type": "array"
    }
  }

We should support things like

export type A = [number, number]

and maybe

export type A = [number, number, number?]

As suspected, we have name collision issue here.

test1.ts

import { RealA } from "./test2";

export interface Parent {
  a: A;
}
export type A = RealA;

test2.ts

export interface RealA {
  a: A;
}
export type A = string;

./node_modules/.bin/ts-json-schema-generator \
    --path 'test.ts' \
    --type 'Parent' \
    --expose 'export' \
    --jsDoc 'extended'

Output: (A in test1.ts is gone!)

{
  "$ref": "#/definitions/Parent",
  "$schema": "http://json-schema.org/draft-06/schema#",
  "definitions": {
    "A": {
      "type": "string"
    },
    "Parent": {
      "additionalProperties": false,
      "properties": {
        "a": {
          "$ref": "#/definitions/A"
        }
      },
      "required": [
        "a"
      ],
      "type": "object"
    },
    "RealA": {
      "additionalProperties": false,
      "properties": {
        "a": {
          "$ref": "#/definitions/A"
        }
      },
      "required": [
        "a"
      ],
      "type": "object"
    }
  }
}

In 1061ba1, we removed unused defs. But we should do the same for extended properties.

Reported by @arvind on slack.