#48 ($recursiveAnchor and $recursiveRef), they're defined only for the ajv. They're not the regular JSON schema spec.

Therefore, support regular spec JSON schema generator for the third party libraries.

When descriptive comments are written on the type, revive in onto the JSON schema.

Descripted Type

/**
 * Member information.
 */
interface IMember
{
    /**
     * Primary Key.
     */
    id: string | null;

    /**
     * Email address.
     */
    email: String;

    /**
     * Real name.
     */
    name: string;

    /**
     * Sex of the member.
     */
    sex: "male" | "female" | 1 | 2 | null;

    /**
     * Age, but omittable.
     */
    age: number | null;

    /**
     * Is dead or alive.
     */
    dead: boolean | null;
}

Transformed code

const stringify = src_1.default.createStringifier(() => ({
    "schema": {
        "$ref": "components#/schemas/IMember"
    },
    "components": {
        "schemas": {
            "IMember": {
                "$id": "IMember",
                "type": "object",
                "properties": {
                    "id": {
                        "type": "string",
                        "nullable": true,
                        "description": "Primary Key."
                    },
                    "email": {
                        "type": "string",
                        "nullable": false,
                        "description": "Email address."
                    },
                    "name": {
                        "type": "string",
                        "nullable": false,
                        "description": "Real name."
                    },
                    "sex": {
                        "oneOf": [
                            {
                                "type": "number",
                                "nullable": true,
                                "description": "Sex of the member."
                            },
                            {
                                "type": "string",
                                "nullable": true,
                                "description": "Sex of the member."
                            }
                        ]
                    },
                    "age": {
                        "type": "number",
                        "nullable": true,
                        "description": "Age, but omittable."
                    },
                    "dead": {
                        "type": "boolean",
                        "nullable": true,
                        "description": "Is dead or alive."
                    }
                },
                "nullable": false,
                "required": [
                    "id",
                    "email",
                    "name",
                    "sex",
                    "age",
                    "dead"
                ],
                "description": "Member information."
            }
        }
    }
}));

Implementing #63 is possible, therefore supporting enumeration type may possible, too.

To enforce user to specify the generic argument, declare like below:

export function createStringifier(): never;
export function createStringifier<T>(): (input: T) => string;

When generic Array alias type comes, typescript-json understands it as an object who has only the length: number property.

Therefore, study the TypeScript Compiler AST again and find solution for the special case.

{
    when_generic_array_alias_type_comes: {
        type: "object",
        properties: {
            length: {
                type: "number",
                nullable: false
            }
        },
        nullable: false,
        required: [
            "length"
        ]
    }
}

#60

Add a benchmark program more, measuring performance including optimizer plan building time.

The benchmark result may be different with #60, especially "TSON.stringify() v2" would be the slowest one.

Summary

When template library type be used in the generic argument, it becomes an error.

• SDK Version: 2.1.5
• Expected behavior: No problem
• Actual behavior: Becomes invliad uri format

Error: schema is invalid: data/$ref must match format "uri-reference"

Code occuring the bug

import TSON from "typescript-json";

interface IPointer<T> {
    value: T;
}
TSON.stringify<IPointer<`some${string}`>>(input);

Design those structures and let factories to return them:

• IJsonApplication
• IJsonComponents
• IJsonSchema

The JSON schema and its related libraries like fast-json-stringify or ajv never can solve the #28 problem.

Therefore, give up using the JSON schema and implement the faster JSON.stringify() function by myself.

The my new way will solve the #28 problem and would be much faster than fast-json-stringify.

Analyzing the fast-json-stringify library, I found the reason why those test function occur erros.

The reason was on return type of the Object.JSON() methods in those test functions. All of them are returning the atomic value and fast-json-stringify does only calls the Object.JSON() method when the JSON schema type is object. In such reason, atomic typed JSON schema like below test codes occurs the JSON string conversion error.

Therefore, when Object.toJSON() returns an atomic typed value, just use the JSON.stringify() function.

• test_stringify_to_json_class.ts
• test_stringify_to_json_class_closure.ts
• test_stringify_to_json_object_closure.ts

The ajv supports not only stringify but parse function, too.

Therefore, make a new branch features/ajv and try to replace core library from fast-json-stringify to the ajv.

If the ajv is enough suitable like the fast-json-stringify, provide the mode option to select the core library.

Name of the components.schemas to follow its origin type name and add incremental value only when duplicated type name exists.

However, as the JSON schema pointer needs duplicate definition for both nullable and non-nullable types, the naming convension always include the nullable symbol like ISystem.ICommit.NonNullable. Also, when a target type has < and > syntax because it has generic parameter(s), change the < and > words to be compatible with URL patterns by replacing keywords.

samchon/nestia#68

My another library nestia is planning to build the swagger.json and the swagger.json also utilizes the JSON schema, too. Therefore, refactor MetadataFactory to be reusable. Also, pointer address of the fast-json-stringify and swagger.json is different, therefore refactor the MetadataFactory to be compatible for them.

https://github.com/samchon/typescript-json/blob/c6a2f06b3579efed953fd9349d176ae1c746df6e/test/features/test_stringify_object_primitive.ts

Considered as any type

This should be possible:

import TSON from "typescript-json";
import { RandomGenerator } from "../internal/RandomGenerator";

export function test_stringify_object_implicit(): void
{
    const lecture: ILecture = {
        name: RandomGenerator.string(),
        professor: RandomGenerator.string(),
        grade: RandomGenerator.number()
    };
    const implicit: string = TSON.stringify(lecture);
    const explicit: string = TSON.stringify<ILecture>(lecture);
}

interface ILecture
{
    name: string;
    professor: string;
    grade: number;
}

Implementing the #41, I've found the bug.

The bug has been reported to the fast-json-stringify.

fastify/fast-json-stringify#413

Do not consider tuple type as an array type containing union typed children.

JSON schema supports the tuple type like below

https://stackoverflow.com/questions/34334376/json-schema-for-array-of-tuples

Benchmark for real use cases.

Also, the benchmark program would not compare only with JSON.stringify() and TSON.stringify(). It would compare a manual programmed JSON string conversion function, who would be generated by the v3. Therefore, the benchmark program would be composed like below:

As typescript-json supports JSON schema generations, it would better to move crypto.randomUUID() polyfill from main file to the StringifyFactory, who generates the faster JSON.stringify() function.

When such interface has been targeted,

interface ILecture
{
    name: string;
    professor?: string | number;
    grade: number | undefined;
}

JSON schema must represent the optional (undefindable) property through the required field.

{
    type: "object",
    properties: {
        name: {
            type: "string",
            nullable: false
        },
        professor: {
            anyOf: [
                {
                    type: "string",
                    nullable: false
                },
                {
                    type: "number",
                    nullable: false
                }
            ]
        },
        grade: {
            type: "number",
            nullable: false
        }
    },
    nullable: false,
    required: [
        "name"
    ]
}

Refactor JsonFactory and SchemaFactory to be much effiently. Especially, the JsonFactory code is too complicate and inefficient as it has hard coded to build the ts.Exression only for the fast-json-stringify Schema. I think creating a new ExpressionFactory who can use every typed value would be much powerful and efficient. Maybe, its code would be even much shorter than the JsonFactory

Therefore, rename the SchemaFactory to the MetadataFactory and separate the JsonFactory to the SchemaFactory and ExpressionFactory, who converts IMetadata to JSON schema and converts any instance to the ts.Expression.

When union type comes, there's no difference between them, only within framework of the JSON.stringify() function booster.

However, when user of this typescript-json imports the SchemaFactory by itself, it would be a matter, as oneOf is the exact use case for that union type. Therefore, change the SchemaFactory to use the oneOf statement instead of the anyOf

TypeChecker.isArrayType() is hidden but exists.

microsoft/TypeScript#37711

Until developer of the fast-json-stringify fix the fastify/fast-json-stringify#406 issue, avoid the $ref error by defining duplicated schema in the external definition with nullable true and false.

저희 회사 "아키드로우" 에서, 삼촌과 함께 일할 프론트 개발자 분들을, 최고의 대우로 모십니다.

"아키드로우" 는 3D (인테리어) 에디터 및 이에 관한 파생 솔루션들을 만드는 회사입니다. 다만 저희 회사의 주력 제품이 3D 에디터라 하여, 반드시 3D 내지 랜더링에 능숙해야 하는 것은 아니니, 일반적인 프론트 개발자분들도 망설임없이 지원해주십시오.

그리고 저희 회사는 분위기가 다들 친하고 즐겁게 지내는 분위기입니다. 더하여 위 typescript-json 이나 nestia 및 payments 등, 제법 합리적(?)이고 재미난 프로젝트들을 다양하게 체험해보실 수 있습니다.

• 회사소개서: archidraw.pdf
• 기술 스택: React + TypeScript
• 이력서: 자유 양식
• 지원처: [email protected]

Instead of using primitive value type like string, try the const type.

https://json-schema.org/understanding-json-schema/reference/generic.html#constant-values

To support #49, JSON schema interface types must be designed.

When using TSON.createSchema() for the swagger.json generation, empty valued IJsonComponent.IObject.required becomes an error (warning level). No matter to building entire swagger.json, but the error message seems annoying. Therefore, change the IJsonComponent.IObject.required type to be optional and make it to be undefined for the empty array.

What had to be done from the beginning.

It's too late but even now.

Reading the compile-json-stringify documents, it seems much faster than fast-json-stringify and ajv when object.

Therefore, also try the compile-json-stringify, too.

If it 's also suitable, provide mode option who can select the core library.

To support such complicate union and recursive type, $recursiveAnchor and $recursiveRef` must be supported.

Without supporting those tags, one of below erros would be occured:

• Error: schema with key or id "IDirectory" already exists bug
• MissingRefError: can't resolve reference components#/schemas/IDirectory from id IDirectory

// BUCKET & DIRECTORY
type IBucket = IDirectory | IFile;
namespace IBucket
{
    export interface IBase<Type extends string>
    {
        type: Type;
        id: string;
        name: string;
    }
}
interface IDirectory extends IBucket.IBase<"directory">
{
    children: IBucket[];
}

// FILES
type IFile = IImageFile | ITextFile | IZipFile;
namespace IFile
{
    export interface IBase<Extension extends string>
        extends IBucket.IBase<"file">
    {
        extension: Extension;
        size: number;
    }
}
interface IImageFile
    extends IFile.IBase<"jpg"|"png"|"gif">
{
    width: number;
    height: number;
    url: string;
}
interface ITextFile
    extends IFile.IBase<"txt"|"md"|"ts">
{
    content: string;
}
interface IZipFile
    extends IFile.IBase<"zip">
{
    files: number;
}

Create a new facade function that returning JSON schema and components.

/**
 * JSON Schema Application.
 * 
 * Creates a JSON schema application which contains both main JSON schema and components. 
 * Note that, all of the object types are stored in the {@link IJsonApplication.components} 
 * property for the `$ref` referencing.
 * 
 * @template T Target type
 * @return JSON schema application
 * @author Samchon
 */
export function createApplication<T>(): IJsonApplication;

swagger-api/swagger-editor#2638

The tuple type has been adopted in the OAS 3.1, but swagger editor is not supporting it.

Therefore, when building JSON schema for swagger generation, use oneOf options instead.

Bug Report

Note that, the bug you're reporting may have registered in the issues by another user. Even the bug you're reporting may have been fixed in the @next version. In such reasons, I recommend you to check the old issues and reproduct your code with the @next version before publishing the bug reporting issue.

`npm install --save-dev typescript-json@next`

When the same error occurs even in the @next version, then please fill the below template:

Summary

When a literal named property from an object type comes, it becomes a runtime error.

• SDK Version: 2.1.0-dev.20220505
• Expected behavior:
• Actual behavior:

Write detailed description in here.

Error: ""something-interesting-do-you-want?"" is required!

Code occuring the bug

import TSON from "typescript-json";

export function test_stringify_object_literal_property()
{
    const property: ILiteralProperty = {
        "something-interesting-do-you-want?": "what's that",
        "or-something-crazy-do-you-want?": "nope"
    };
    const json: string = TSON.stringify(property);
    const expected: string = JSON.stringify(property);

    if (json !== expected)
        throw new Error("Bug on TSON.stringify(): failed to understand the object literal property.");
}

interface ILiteralProperty
{
    "something-interesting-do-you-want?": string;
    ["or-something-crazy-do-you-want?"]: string;
}

It's not functional. Let's replace all of the let statements to the const.

Like below example cases, when generic typed object or its alias type comes, typescript-json cannot parse the generic typed properties and considers them as the unknown type. Therefore, no error be occured, but the JSON string conversion speed is not fast, either.

Generic typed object

import TSON from "../../src";

export function test_stringify_object_generic_alias(): void
{
    const something: ISomething<string> = {
        value: "value",
        child: {
            child_value: "child_value",
            child_next: "child_next"
        },
        elements: ["one", "two", "three"],
    };
    const json: string = TSON.stringify<ISomething<string>>(something);
    const expected: string = JSON.stringify(something);

    if (json !== expected)
        throw new Error("Bug on TSON.stringify(): failed to understand the generic object type.");
}

interface ISomething<T>
{
    value: T;
    child: IChild<T>;
    elements: T[];
}
interface IChild<U>
{
    child_value: U;
    child_next: U;
}

Generic alias type of the generic typed object

import TSON from "../../src";
import { Primitive } from "../internal/Primitive";

export function test_stringify_object_generic_alias(): void
{
    const alias: Alias = {
        value: "Something"
    };
    const stringify: (input: Alias) => string = TSON.createStringifier<Alias>();
    
    const json: string = stringify(alias);
    const parsed: Alias = JSON.parse(json);

    if (Primitive.equal_to(alias, parsed) === false)
        throw new Error("Bug on TSON.createStringifier(): failed to understand the object alias type.");
}

interface ISomething<T>
{
    value: T;
}
type Alias = ISomething<string>;

When #68 becomes come true, the README should be revised.

Never forget to adding this title in the revised README

1,000x times faster than fast-json-stringify

Write community documents:

• issue templates
  • bug report
  • feature request
  • question
• pull request template
• code of conduct
• contributing

Implement faster JSON.stringify() function by myself.

It would be v3 update and its JSON string conversion speed would be much faster than v2. The JSON string conversion speed would be 3x times faster than before (would be thoundands times faster when considering the optimizer plannig time). Also, the v3 does not utilize the JSON schema, but TypeScript type directly. Therefore, typescript-json would be much safer than ordinary v2.

typescript-json is wrapper library of fast-json-stringify, which can omit JSON schema definition, through the TypeScript Compiler API with transformer. In such reason, providing maximum convenience to users with minimum effort was possible, by developing an automatic JSON schema generator. Furthermore, as typescript-json could define JSON schema automatically, dependent library like nestia could build swagger.json very easily.

However, as adopted fast-json-stringify, typescript-json is following its disadvantages, too.

At 1st, fast-json-stringify is not fast.

The fast-json-stringify requires too much time to constructing faster JSON string conversion function. It analyzes JSON schema at runtime, therefore optimizing the JSON string conversion plan time is required, and it outcomes below result. As you can see from the below graph, optimizer planning time makes fast-json-stringify slower, than the native JSON.stringify(), about hundres times. Even measuring only JSON conversion speed, fast-json-stringify is slow too, when recursive relationshp comes.

However, if I change typescript-json to optimize the JSON string conversion plan in the compilation level, through the TypeScript Compiler API with transformer, the conversion speed would not be slow by constructing the optimizer plan. Also, as typescript-json knows exact type of the target data, optimizer plan would be much evolved than before.

• #60
• #61

Include optimizer planning time	Only JSON string conversion time

At 2nd, fast-json-stringify is not enough stable.

fast-json-stringify is utilizing ajv library as dependency and the ajv library occurs an error when composite structured object type comes. Even the ajv is using non-standard feature $recursiveRef, which does not defined in the JSONS schema. However, the $recursiveRef be broken when complicated structure comes.

However, if I develop JSON string conversion logic by myself, such bug would not be occured.

• fastify/fast-json-stringify#417
• #42
• #48
• #48

At last, TypeScript type is much superior than the JSON schema.

Developing the JSON schema generator from the TypeScript type, I understood that how TypeScrip type is superior and how JSON schema is inferior, within framework of the TypeScript user. Therefore, when developing TypeScript library boosting up the JSON string conversion speed, using pure TypeScript type is much better.

For example, fast-json-stringify and ajv cannot understand the Object.toJSON() method, because they don't know original types of parameters. With fast-json-stringify, to solve the below bug, custom JSON string conversion must check all of the values whether they're a type of object and has a toJSON() method or not, via recursive visit strategy. However, it would make JSON string conversion speed much slower.

However, if v3 comes, the toJSON() methods would be exactly traced in the compilation level.

• fastify/fast-json-stringify#405
• #28