typescript-resolvers mappers do not take emitLegacyCommonJSImports: false into account

[ldrick]

Which packages are impacted by your issue?

@graphql-codegen/typescript-resolvers

Describe the bug

Once generating ESM compatible output, imports in Typescript are needed to resolve to .js. Using @graphql-codegen/typescript-resolvers with mappers doesn't write the imports correctly, even having emitLegacyCommonJSImports: false configured

Your Example Website or App

https://the-guild.dev/graphql/codegen

Steps to Reproduce the Bug or Issue

1. Go to https://the-guild.dev/graphql/codegen
2. add this codegen.yml:

generates:
  resolvers.ts:
    config:
      emitLegacyCommonJSImports: false
      mappers:
        User: ./models#UserDbObject
        Chat: ./models#ChatModel
    plugins:
      - typescript
      - typescript-resolvers

3. see the resolvers.ts being generated with this import:

import { UserDbObject, ChatModel } from './models';

Expected behavior

resolvers.ts shall be generated with this import:

import { UserDbObject, ChatModel } from './models.js';

Screenshots or Videos

No response

Platform

• OS: Linux
• NodeJS: 18.15.0
• graphql version: 16.6.0
• @graphql-codegen/typescript version: 3.0.3
• @graphql-codegen/typescript-resolvers version: 3.2.0

Codegen Config File

No response

Additional context

Workaround:

generates:
  resolvers.ts:
    config:
      emitLegacyCommonJSImports: false
      mappers:
        User: ./models.js#UserDbObject
        Chat: ./models.js#ChatModel
    plugins:
      - typescript
      - typescript-resolvers

[csimmons0]

~Is there a workaround for this?~

EDIT: I'm a dummy and didn't see the stated workaround in the OP. In fact, after seeing the workaround, I'm not sure this is a bug. Requiring us to explicitly put the .js on the file path that we specify isn't crazy. And is it possible that someone would need to use the .cjs or .mts extension in some cases? If so, then this tool needs to let us specify the extension instead of inferring it.

[eddeee888]

Hi, I feel the workaround is the right way to do it as we are taking control over the import path and the typing. Any reason why not use the said method?

[csimmons0]

Also note that this issue affects the contextType and scalars settings in the same way that it affects mappers.