fix(visitor-plugin-common): Use rhs of 'import as' statements #9100

[Otard95]

🚨 IMPORTANT: Please do not create a Pull Request without creating an issue first.

Any change needs to be discussed before proceeding. Failure to do so may result in the rejection of the pull request.

Description

This PR is created in response to contribution guides "A Typical Contributor Workflow" stage/2-failing-test. As such, this change is for the moment just a failing test that reflects the issue.

EDIT: Implemented possible solution as described in https://github.com/dotansimha/graphql-code-generator/pull/9592#issuecomment-1678919861

This PR is related to the #9100 issue.

Short recap of the issue

When the TypeScript enum and the GraphQL enum aren't named identically the generated resolver types are invalid and will not compile.

With the following config

{
    "enumValues": {
        "MyGqlEnum": "@swydo/foo#MyTsEnum"
    }
}

the following is generated:

import { MyTsEnum as MyGqlEnum } from '@swydo/collections';

export type ResolversTypes = {
    MyGqlEnum: MyTsEnum;
}

Type of change

• [x] Bug fix (non-breaking change which fixes an issue)

Screenshots/Sandbox

Sandbox provided by @quintstoffers in the original issue: https://codesandbox.io/s/graphql-codegen-enum-types-wt98s9?file=/resolvers.ts

I've also created a repo reproducing the issue: https://github.com/Otard95/graphql-code-generator-issue-reproduction

How Has This Been Tested?

As described by stage/2-failing-test at this point this is just a draft PR with a failing test.

• [x] TypeScript Resolvers Plugin › issues › #​9100 - should use the rhs of 'import as' when using external enum with different name

Test Environment:

• OS: Linux 6.1.0-11-amd64 Debian 6.1.38-4 (2023-08-08) x86_64 GNU/Linux
• [email protected]
• @graphql-codegen/[email protected]
• @graphql-codegen/[email protected]
• @graphql-codegen/[email protected]
• NodeJS: v18.15.0

Checklist:

• [x] I have followed the CONTRIBUTING doc and the style guidelines of this project
• [x] I have performed a self-review of my own code
• [x] I have commented my code, particularly in hard-to-understand areas

• [x] My changes generate no new warnings
• [x] I have added tests that prove my fix is effective or that my feature works
• [x] New and existing unit tests pass locally with my changes
• [ ] Any dependent changes have been merged and published in downstream modules
  • Not sure if this is necessary as the change is in a single package, and I don't know if I'd need to manually update the dependency version in other packages, or if this is automated.

Further comments

I'm unsure how much time I can devote to this, but I hope this could at the very least help move this issue forward and spark some discussion.