avoid namespace imports for enums

[schmod]

Description

This PR slightly modifies TypeScript code-generation to use idiomatic ES6-style imports (where possible) when importing custom enumValues.

Currently, the following config:

{ enumValues: { MyEnum: './my-file#MyCustomEnum' } }

will produce

import { MyCustomEnum } from './my-file';
import MyEnum = MyCustomEnum;
export { MyEnum };

The namespace import (on the second line above) is a fairly unusual bit of TypeScript syntax. Some third-party parsers (such as Babel) have difficulty parsing it. In this scenario, the namespace import is also entirely unnecessary, as we can specify our alias in the original import statement.

---

After this PR, the output becomes:

import { MyCustomEnum as MyEnum } from './my-file';
export { MyEnum };

This output should be equivalent in terms of functionality, is slightly more readable and compact, and should be better-tolerated by tools that do not understand TypeScript namespaces.

MyCustomEnum is no longer available as a variable in the generated file, although I would not imagine that any reasonable person would expect it to be. (If anything, this change slightly reduces the odds of unintentional naming collisions)

---

This PR does not attempt to resolve this issue for deeply-nested imports such as:

{ enumValues: { MyEnum: './my-file#NS.MyEnum' } },

import { NS } from './my-file';
import MyEnum = NS.MyEnum;
export { MyEnum };

I'm less confident in my ability to write 100%-equivalent code here that does not utilize namespace imports, and I would also imagine that this scenario is considerably less common.

Related #4236

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

This functionality is covered by existing unit tests, which have been modified to reflect the new expected output.

Changes to the generated code should be no more complicated than the example described above.

Checklist:

• I have followed the CONTRIBUTING doc and the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[changeset-bot]

🦋 Changeset detected

Latest commit: d742879

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 9 packages

Name	Type
@graphql-codegen/visitor-plugin-common	Patch
@graphql-codegen/typescript-document-nodes	Patch
@graphql-codegen/gql-tag-operations	Patch
@graphql-codegen/typescript-operations	Patch
@graphql-codegen/typescript-resolvers	Patch
@graphql-codegen/typed-document-node	Patch
@graphql-codegen/typescript	Patch
@graphql-codegen/graphql-modules-preset	Patch
@graphql-codegen/client-preset	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[Hugodby]

Hello, this has introduced a regression here: #9100

Any hint on how to fix it?