Failure on TypeScript files that contain `satisfies` keyword

[awx-doma-lei]

Which packages are impacted by your issue?

@graphql-codegen/cli

Describe the bug

Hey team, I just encountered this problem that graphql-codegen fails when an operation is located in a TypeScript file that contains the satisfies keyword. Upgrading all @graphql-codegen/* dependencies didn't help. Strangely enough, when I tried to reproduce with a fresh project, putting in the same plugins, configuration and the same TypeScript source code, it worked just fine.

Your Example Website or App

https://github.com/awx-doma-lei/graphql-codegen-cli-issue-repro

Steps to Reproduce the Bug or Issue

Run yarn codegen to see the error

Expected behavior

As a user, I expect graphql-codegen to work with my TypeScript files that uses the satisfies keyword.

Screenshots or Videos

No response

Platform

• OS: macOS
• NodeJS: 20.18.1
• graphql version: 16.9.0
• @graphql-codegen/cli version(s): 5.0.2, 5.0.7

Codegen Config File

No response

Additional context

Looking into the error stack, I noticed there's a Missing semicolon error from @babel/parser, and found that it's an earlier version of Babel (7.18.11 in my case) that doesn't support TypeScript 4.9 syntax (it's supported since Babel 7.20.0). But in the fresh project, the installed Babel was the latest, and that explained the issue.

Babel was depended on by @graphql-codegen/cli through the following chain:

@graphql-codegen/cli
-> @graphql-tools/{code-file-loader,git-loader,github-loader}
   -> @graphql-tools/graphql-tag-pluck
      -> @babel/parser

The reason that upgrading didn't work despite the latest @graphql-tools/graphql-tag-pluck already requires a higher version of Babel (7.26.0) since 8.3.18 was that the latest @graphql-codegen/cli's dependencies is still as tolerant as ^8.0.0, so @babel/parser didn't get updated when I upgraded @graphql-codegen/cli.

I think we should update @graphql-codegen/cli's package.json to require the newer versions of @graphql-tools/* dependencies to ensure a higher version of Babel and hence to ensure the support of TypeScript 4.9.

[eddeee888]

Hi @awx-doma-lei ,

You can usually force package versions using yarn resolutions on existing repos:

1. Use resolutions to target your package (@babel/parser in this case), making sure it's in the right version range
2. yarn install, confirm the version in yarn.lock updates
3. Remove resolutions
4. yarn install again

As you said, new repos don't have this issue, so it should be fixed in old repos. 🙂

[SevenOutman]

Thanks @eddeee888. But I still believe it's an enhancement that this library could make.
Is there any concerns if we update the package's dependencies?

[eddeee888]

Hi @SevenOutman ,

Generally, libraries leave versions very wide to allow consumers pick and choose the one that works for them.

Main concern/considerations: if we updated the selected version, then we need to release a patch/minor/major version for codegen packages - which forces every user to update their version. I don't think this is fair for majority of the userbase as we are not bringing any values to them, just renovates noise.

[SevenOutman]

@eddeee888 I see your point.

graphql-codegen doesn't depend on graphql-tools as peerDependencies but dependencies, so I think there's nothing for the users to choose from. This also means that updating the dependency versions - especially non-major updates - won't result in a major bump of graphql-codegen itself. It's rather an improvement/bug to the library itself the requires only a minor/patch bump, depending on how we see the issue.

[eddeee888]

so I think there's nothing for the users to choose from

Users can always choose the version of deps using yarn resolutions (or equivalent in npm, pnpm, etc).
It's usually faster for users to resolve their lockfile by themselves, rather than waiting for PR to be approved, packages to be released, etc. 🙂

This also means that updating the dependency versions - especially non-major updates - won't result in a major bump of graphql-codegen itself. It's rather an improvement/bug to the library itself the requires only a minor/patch bump, depending on how we see the issue.

I think any version bump could be noisy to majority of users, so I'd like to avoid it where possible.
There are exceptions to this approach of course, but I don't think this case would be it.

[eddeee888]

Closing this as this can be solved in consumers' repo.