Graphql-code-generator: support for importing mapper as default more than once

[cainlevy]

Describe the bug

I am using typescript-resolvers with configured mappers to integrate my ORM entities with my API. My entities are exported from their individual files as default.

My goal now is to begin a data type migration by adding the same entity to my API in two places. However, when I try to import the single entity with two identifiers, the generated import code only imports the first identifier.

This appears to be a limitation in BaseResolversVisitor#buildMapperImport where it assumes that a default import will only have one identifier.

https://github.com/dotansimha/graphql-code-generator/blob/563c9dc9007d36b026f84258443c4df31603558f/packages/plugins/other/visitor-plugin-common/src/base-resolvers-visitor.ts#L732

To Reproduce

CodeSandbox failed to load with a 502 Bad Gateway. I hope my description and code link should be enough to confirm the issue.

1. My GraphQL schema:

type Query {
  model: MyModel
  newModel: MyNewModel
}

1. My GraphQL operations:

n/a

1. My codegen.yml config file:

generates:
  src/schema.ts:
    plugins:
      - typescript
      - typescript
    config:
      mappers:
        MyModel: ./MyModel#default
        MyNewModel: ./MyModel#default

Expected behavior

import MyModel from `./MyModel`;
import MyNewModel from `./MyModel`;

Environment:

• OS: Linux
• @graphql-codegen/...: 1.17.7
• NodeJS: 14.x

Additional context

[dotansimha]

@cainlevy can you please explain why does it matter? I mean, if it's pointing to the same variable eventually?

You can also do:

        MyModel: ./MyModel#default as Something
        MyNewModel: ./MyModel#default as SomethingElse

But I think it might still import it only once (but with a custom name).

[cainlevy]

The reason it matters to me is because I have two GraphQL types. Yes, they are mapped to the same model type eventually, but they have different identifiers.

My workaround was to export my model type twice with different names so that I didn't rely on #default. That was easy once I discovered and understood the limitation. Removing the limitation could save the next developer a bit of wasted time though.

I should also note that the current behavior creates broken types. The two identifiers (MyModel and MyNewModel) are used properly in the generated types, but only the first is defined through the import. The second creates a TypeScript error.

[dotansimha]

I see, thanks.
Personally, I always try to avoid using default imports, since it's very hard to refactor and work with :)

I will try to find a way to fix that :)