Future of relay-operation-optimizer with Relay 13?

[orta]

Describe the bug

Hi folks, Relay started shipping version 13 which includes their rust compiler, making relay-compiler look like this:

Cool for the Relay folks, but less cool for this package as it relies on the relay compiler JS and will now bail when you have that dependency set up in the app.

To Reproduce
Steps to reproduce the behavior:

{
  "resolutions": {
    "relay-compiler": "13.0.0-rc.1"
  }
}

Options

• Vend that code from the old compiler?
• Remove the dependency from the graphql-codegen?

[n1ru4l]

@orta That is a great question and concern. We have been talking about this internally and for the meanwhile staying on v12 seems to be sufficient for the current version as afaik v13 does not bring any benefits for the current codegen use-cases.

It might be possible to leverage relay-compiler 13 somehow within graphql-codegen, however, we also have concerns that for most use-cases running native binaries only brings overhead and headaches compared to just running Node.js code. However, we are not completely against exploring how we can use binaries in the future for parts of graphql-codegen in order to achieve better performance for larger code-bases.

We also thought about creating a completely new operations plugin (codename "operations-2") that uses an intermediate representation (IR) instead of simply a visitor that would allow being more flexible for adding such transforms, it could potentially use the relay-compiler 12 code as the basis.

[ardatan]

Moving this to the Discussions

[SimenB]

Any news on this? It blocks our migration to graphql@16 (via graphql-codegen) 🙂

[n1ru4l]

For now, the most straightforward solution is to inline the relevant relay code within codegen. Any contributions regarding this are welcome.

[CarsonF]

FWIW, @graphql-tools/relay-operation-optimizer was never even used in my application.
I just faked the package resolution (I'm using Yarn v3) to allow @graphql-tools/visitor-plugin-common to load successfully. This ignores the relay-compiler dependency all together.

  "resolutions": {
    "@graphql-tools/relay-operation-optimizer": "npm:lodash@*"
  }

Could be worth checking whether its optimizeDocuments function is used and doing the same thing.

[eldarshamukhamedov]

Using "@graphql-codegen/typescript": "2.4.8" and "graphql": "16.2.0" with PNPM will cause a peer dependency check to fail:

 ERR_PNPM_PEER_DEP_ISSUES  Unmet peer dependencies

.
└─┬ @graphql-codegen/typescript
  └─┬ @graphql-codegen/visitor-plugin-common
    └─┬ @graphql-tools/relay-operation-optimizer
      └─┬ relay-compiler
        └── ✕ unmet peer graphql@^15.0.0: found 16.2.0

This occurs because, unlike NPM and Yarn, PNPM strictly enforces peer dependency resolution.

Luckily I don't use Relay, so a PNPM workaround is to override the relay-compiler peer dep for graphql like this:

module.exports = {
  hooks: {
    readPackage: (packageJson, context) => {
      switch (packageJson.name) {
        case 'relay-compiler': {
          packageJson.peerDependencies = {
            ...packageJson.dependencies,
            graphql: '^15.0.0 || ^16.0.0',
          };
          return packageJson;
        }
      }
      return packageJson;
    },
  },
};

If you do use Relay, chances are the above will severely break the functionality of @graphql-codegen/typescript, so I can't recommend this approach. I believe the only way to use @graphql-codegen/typescript with PNPM and Relay is to downgrade to "graphql": "16.2.0".

Please consider upgrading the package to relay-compiler@13. 🙏

[glasser]

Would it be possible to break the dependency from @graphql-codegen/visitor-plugin-common on @graphql-tools/relay-operation-optimizer somehow so that only relay users end up with this in their dependency tree, not every user of @graphql-codegen/typescript? Maybe even as an optional peer dep that you have to install to use flattenGeneratedTypes or something?

[ardatan]

After this release, peer dependency issue will no longer exist;
#4518