Does this work for gql imported from @apollo/client?

[jaydenseric]

The readme doesn't make it clear if this Babel plugin is able to replace gql when it is imported from places other than graphql-tag; namely @apollo/client.

I tried to load this plugin in the Babel REPL to find out, but it never loads successfully. In a Next.js repo, looking at the resulting bundle, it seems to not work?

No one could answer the question here. I'm surprised the community hasn't smoothed this over yet, since Apollo is advising everyone to import gql from @apollo/client for Apollo Client v3 which had a very long beta period:

The @apollo/client package includes graphql-tag as a dependency and re-exports gql. To simplify your dependencies, we recommend importing gql from @apollo/client and removing all graphql-tag dependencies.
— https://www.apollographql.com/docs/react/migrating/apollo-client-3-migration/#graphql-tag

This seems like bad advice. They don't even follow their own advice in their "Compiling queries with Babel" docs:

This approach will allow you to use the graphql-tag library as usual
— https://www.apollographql.com/docs/react/performance/babel/#using-babel-plugin-graphql-tag

Maybe Apollo didn't give much thought to performance when designing and documenting their new API?

Either way, if this plugin doesn't handle gql imported from @apollo/client it probably needs to moving forward.

[StefanYohansson]

https://github.com/StefanYohansson/babel-plugin-graphql-tag/tree/feat/add-apollo-v3-support

I made a branch for this and I have a big project to test it. I am including this branch there and changing imports from graphql-tag to @apollo/client in order to test.

Get back here when things works (or crashes lol)

EDIT: it works for me :)
#44

[StefanYohansson]

Moving the discussion regarding require() to this issue.

based on @jaydenseric last comment on my PR

It would be nice if by default it would process all the known ways gql is imported, zero config FTW.

I have some problems making "all the known ways" because it is pretty much open for interpretations based on developer imagination:

const IdislikeGqlName = require('./myutilsthatexportgql');

So I changed from importName: string to importSources: array<string> this way we can validate more than one with default ['graphql-tag', '@apollo/client'] and if for some reason the system is on the process of migration/refactor it doesn't break everything if guys screw things with mix of './myutilsthatexportgql', 'graphql-tag', '@apollo/client'.

It is really hard to cover all the bases when it is broadly open to interpretation.

Another problem that I found is regarding destructing after import in the case of new '@apollo/client'

import apolloClient from '@apollo/client';

const { gql } = apolloClient;

const foo = gql`...`;

I hope someone doesn't use things like that :/

Btw, require is working alongside this importSources modification on this PR: #45

[theogravity]

Should we ignore the peerDependency for graphql-tag if we're using the v3 apollo client?

[drewlustro]

Could the maintainers chime in? Does this work for @apollo/client?

I came to the same conclusion as @jaydenseric. Some quick issue doomscrolling led me here.

[drewlustro]

Nevermind, thanks!

It looks like the case is officially supported. I thought it was still problematic because this issue remained open.