Error "Type has multiple definitions" thrown when types with same name are found

The generator currently doesn’t like types in different files having the same name:

// test2.ts
export type Field = string | number;

// test.ts
import { Field as Field2 } from "./test2";

export type Field = string;

export type MyObject = {
    a: Field;
    b: Field2;
};

When generating the schema for MyObject then the generator stops with this error:

/home/k/Projects/ts-json-schema-generator/dist/ts-json-schema-generator.js:33
        throw error;
        ^

Error: Type "Field" has multiple definitions.
    at /home/k/Projects/ts-json-schema-generator/dist/src/SchemaGenerator.js:69:23
    at Array.reduce (<anonymous>)
    at SchemaGenerator.appendRootChildDefinitions (/home/k/Projects/ts-json-schema-generator/dist/src/SchemaGenerator.js:66:14)
    at /home/k/Projects/ts-json-schema-generator/dist/src/SchemaGenerator.js:21:44
    at Array.forEach (<anonymous>)
    at SchemaGenerator.createSchema (/home/k/Projects/ts-json-schema-generator/dist/src/SchemaGenerator.js:21:19)
    at Object.<anonymous> (/home/k/Projects/ts-json-schema-generator/dist/ts-json-schema-generator.js:22:56)
    at Module._compile (internal/modules/cjs/loader.js:774:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:785:10)
    at Module.load (internal/modules/cjs/loader.js:641:32)

[mipearson]

Apologies for necro-ing this, but I figured it was more polite to comment here than open a new issue.

I agree with what you’ve said - that it’s good to avoid having a project where the same name is used twice - but I’ve just hit an issue where I’m generating a schema based on the AWS JS SDK, and I have one type that relies on NetworkConfiguration by proxy via CreateServiceRequest in @aws-sdk/client-ecs and another that refers to NetworkConfiguration directly in @aws-sdk/client-cloudwatch-events.

Because each AWS service is a beast unto itself these are similar but still different types.

Renaming the type by importing as import { NetworkConfiguration as CWNetworkConfiguration } from '@aws-sdk/client-cloudwatch-events' did not work - it still complained about the duplicate type.

Creating an entirely new type by aliasing it, eg: type CWNetworkConfiguration = NetworkConfiguration, did not work.

Creating a new type that TS would infer as being different (even though it isn’t) via type CWNetworkConfiguration = Partial<NetworkConfiguration> then gave me an error about a type that it refers to, AwsVpcConfiguration, and at that point I gave up and copy/pasted the type from AWS’s typedefs and renamed each individual item by hand.

Is there another workaround?

[sramam]

This simple case seems a legitimate and reasonable construction of a program that triggers this error:

ChildA.ts

export interface IProps {
  id: "childA",
  // other props can go here
}

ChildB.ts

export interface IProps {
    id: "childB";
    // other props can go here
}

Parent.ts

import * as ChildA from "./childA";
import * as ChildB from "./childB";

export interface IProps {
    id: "parent",
    // other props can go here
    children: Record<string, ChildA.IProps | ChildB.IProps>
}

$ node dist\ts-json-schema-generator.js -p multi-test/parent.ts

Error: Type "IProps" has multiple definitions.
    at SchemaGenerator.appendRootChildDefinitions (dist/src/SchemaGenerator.js:97:23) 
    at dist\src\SchemaGenerator.js:36:46
    at Array.forEach (<anonymous>)
    at SchemaGenerator.createSchemaFromNodes (dist/src/SchemaGenerator.js:36:19)      
    at SchemaGenerator.createSchema (dist/src/SchemaGenerator.js:25:21)
    at Object.<anonymous> (dist/ts-json-schema-generator.js:70:56)
    at Module._compile (internal/modules/cjs/loader.js:1063:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1092:10)
    at Module.load (internal/modules/cjs/loader.js:928:32)
    at Function.Module._load (internal/modules/cjs/loader.js:769:14)

I’ve been looking at the code to figure a valid discriminant and not sure there is an easy path here. Perhaps using the id instead of the name when there is a conflict? Though ideally, it’d be good to have the file path in the mix, to allow human comprehension.

Wondering if others have figured clever work arounds (renaming is not an option for my use-case).