export aliases are not suported

[paztis]

if interfaces are not directly exported, they are not considered in the schema

This code is well working

export default interface A {...}
export interface B {...}

This one not

interface A {...}
interface B {...}

export default A;
export {B}

The problem is you didn't consider the export of the sourceFile, but only the member of the source file, then check if they're flagged as exported, what is not the case.

[paztis]

Hi create a fork ts-json-schema-generators for my needs (I need the support of functions and promises that was not possible with the JSONSchema7 format) Inside I've fix the issue of exports

you can found my code under this commit in my repo: https://github.com/paztis/ts-json-schema-generator/commit/4eb4c103e492f1a22fee0270e3bf742189bcdb3c Inside, I change 2 things:

• search real export in sourceFile instead of the exportSymbol
• keep fullyQualifiedName in the definitions

The second one is only to avoid name collisions we can have in the definitions.

Nevertheless, you can take a look at my fork, perhaps it will be interesting for you. I review the full management to start from sourceFile, then process all only its exports By creating a sourceFile parser, it removed 90% of hte code in the SchemaGenerator.ts file

I also support the

import * as test from '....";
export {test}

that were not supported in your module

But I know as I forked from the JsONSchema, potentially I'm not compatible with your system. Perhaps we can propose an option to enable / disable it ? and like this we can merge my code ?

[paztis]

Now with my fork, for example, I can process any typescript code normally.

[domoritz]

I would love to merge the improvements. Could you send a pull request for the fixes?

I don't think I want to add support for functions right now as it's not a standard feature of json schema.

[paztis]

as all the commits are in the same branch, it will be hard for me to create the PR. I need to split my commits for this

can you take a look and said me which commits you'd like to get ?

[domoritz]

I think all the fixes (not support for promises and functions) would be awesome.

[paztis]

The processing of the modules is different now. Troy .to run it over examples you classically use to see if the output format is of for you

Le jeu. 13 août 2020 à 17:13, Dominik Moritz [email protected] a écrit :

I think all the fixes (not support for promises and functions) would be awesome.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/vega/ts-json-schema-generator/issues/469#issuecomment-673536992, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABIKMMJFISLNAALDCZOOIGLSAP7IBANCNFSM4PGYZLQQ .

[domoritz]

I don't understand your last message.

[paztis]

I mean can you install my branch and try to generate Json from ts files you use classically ? You will see the output differences and can see if it is correct for you

Le jeu. 13 août 2020 à 18:34, Dominik Moritz [email protected] a écrit :

I don't understand your last message.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/vega/ts-json-schema-generator/issues/469#issuecomment-673580548, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABIKMMLNLQWOIJQBMNXHXRDSAQIYLANCNFSM4PGYZLQQ .

[domoritz]

Why would there be differences for bug fixes / refactorings?

[paztis]

Because the output format was not correct for me

Le jeu. 13 août 2020 à 18:57, Dominik Moritz [email protected] a écrit :

Why would there be differences for bug fixes / refactorings?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/vega/ts-json-schema-generator/issues/469#issuecomment-673591896, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABIKMMJ6LYKJTTESFC5C2PTSAQLN5ANCNFSM4PGYZLQQ .

[domoritz]

@paztis could you send pull requests for your improvements?

[paztis]

Hi

It is hard to split all the features independently. I think I will try to extract all the non standard ones under a form of plugin. What do you think about it ?

In this case we will be able to merge the code correctly.

[domoritz]

That would be great. Thanks for doing the extra work to extracting the relevant changes so we can merge them back.

[andrei-selilo]

Hi @domoritz, any updates on this issue? Having a similar problem.

[domoritz]

There hasn't been a pull request for this feature so not from my side. I'd love to merge the improvements.

[mdesousa]

Getting a fix for this would be great! I'm new to ts-json-schema-generator, and was banging my head because my definitions were coming back empty since we always export at the bottom of our files. While the fix is merged, I would suggest to mention this behavior in the readme.

[cspotcode]

I'm looking at these changes. It seems upstream has already implemented parsing of function types? Does this mean the earlier objections about not merging the function parsing support may have changed?

Merge-base point is 8682879526455f898492707bf5c82face7e46570

Upstream changes since the fork: https://github.com/vega/ts-json-schema-generator/compare/8682879526455f898492707bf5c82face7e46570...next Changes in paztis since the fork: https://github.com/paztis/ts-json-schema-generator/compare/8682879526455f898492707bf5c82face7e46570...master

[cspotcode]

@paztis What is the SpecificObjectTypeFormatter? Do you have an example of when this is parsed and formatted?

[paztis]

Hi Andrew. This one is here to be able to catch object like Html element, or Event and to stop the Parsing here and to return a predifiend object instead.

i do this to avoid to process them as they are too heavy and can be simplified.

I didn't update my code on hit hub since long time now but I've got tons of enhancements done now. I will try to update it.

But the main difference is we're returning a data model that is an extension of JsonSchema while you return an strict one

Le jeu. 5 août 2021 à 18:39, Andrew Bradley @.***> a écrit :

@paztis https://github.com/paztis What is the SpecificObjectTypeFormatter? Do you have an example of when this is parsed and formatted?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/vega/ts-json-schema-generator/issues/469#issuecomment-893602824, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABIKMMLN4QDEYC27V3ELSUTT3K5EBANCNFSM4PGYZLQQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .

[cspotcode]

stop the Parsing here and to return a predifiend object instead.

Do you have a code example that uses this Formatter?

For example:

/**
 * JSDoc here
 * What do I put in the JSDoc so that I can use SpecificObjectTypeFormatter?
 */
export type Foo = {
  // what do I put here so that I can use SpecificObjectTypeFormatter?
}

[cspotcode]

I see, you have a hardcoded mapping between known types and the schema that should be generated for them. So when the parser encounters these types, it totally skips schema extraction, instead using the hardcoded schema.

Sounds similar to what was requested in #795

[cspotcode]

@paztis I'm working on updating the automated tests as necessary. There is a change in the output of top $ref that I am unsure about.

Is this change in behavior intentional?

Tests are expecting a schema like this, which has a top-level $ref pointing to the definition.

{
  "$ref": "#/definitions/MyObject",
  "definitions": {
    "MyObject": {
      "additionalProperties": false,
      "type": "object"
    }
  }
}

Instead, the generated schema looks like this. The top-level schema is described as an object, and the MyObject property references the definition.

{
  "type": "object",
  "properties": {
    "MyObject": {
      "$ref": "#/definitions/'ts-json-schema-generator.test.valid-data.annotation-custom.main'.MyObject"
    }
  },
  "additionalProperties": false,
  "definitions": {
    "'ts-json-schema-generator.test.valid-data.annotation-custom.main'.MyObject": {
      "additionalProperties": false,
      "type": "object"
    }
  }
}

[cspotcode]

It looks like your fork ignores the type and topRef options, instead exporting a schema where each named export of the entrypoint .ts corresponds with a property of the schema. If .ts does export type foo = number; then the schema describes an object with property foo which must be a number.

This is certainly useful, but it must be opt-in; it can't be the only behavior. In order to make these changes merge-able, I will need to re-enable support for type and topRef. Do you have any suggestions for the cleanest way to do that?