feat: add ability to preserve ts file extension

[nickmessing]

Description

Add preserveTSExtension boolean configuration that allows .ts file extensions (for native import without transpilation tools)

Related #10490
Prerequisite for eddeee888/graphql-code-generator-plugins#364

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?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

• Unit tests included
• Tested on a production project to not break anything with old config
• Tested on a production project to add .ts extension when flag is present

Test Environment:

• OS: macOS 26.0.1
• @graphql-codegen/cli: latest
• NodeJS: v25.1.0

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]

⚠️ No Changeset found

Latest commit: 59a10a9

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

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

[nickmessing]

Should I add the changeset too?

[eddeee888]

Hi @nickmessing,
Thanks for the PR! How do you feel if we created a more flexible config option and deprecate emitLegacyCommonJSImports?
For example generatedFileExtension which could be .js, .ts, .mjs, mts, etc.

This way, it's up to the user to configure it for their environment. Otherwise, we'd keep adding booleans and they may override each other

[nickmessing]

Sure, I could do that, but we need a bit better planning for that as .ts and .mts suggest that files themselves should have this extension, while .js and .mjs would be (sometimes) the import format, and we must offer complete flexibility then (.mts files imported as .mjs?)

What about:

interface ConfigOptions {
  outputFileExtension: '.ts' | '.mts' | '.cts',  // default: '.ts'
  importExtension: 'omit' | 'preserve' | 'js-compatible',  // default: 'omit'
}

outputFileExtension is the actual extension of the files that are generated

importExtension:

• omit - import without extension
• preserve - actual file path in import
• js-compatible - similar to emitLegacyCommonJSImports but maps extensions (ts -> js, mts -> mjs, cts -> cjs)

P.S. I would prefer "preserve" for default importExtension, just because both node.js and deno are there now, but reverse-compatible default would be wiser

wdyt @eddeee888

[eddeee888]

Hi @nickmessing ,
I wonder if the following one option covers all the cases?

outputFileExtension: 
  | '' // no extension
  | '.ts' 
  | '.js'
  | '.mts' 
  | '.mjs'
  | '.cts'
  | '.cjs'

[nickmessing]

If it's configured as .mjs, files themselves should be .mts?
This could work

[nickmessing]

I'll close this PR, let's discuss in #10490