Error after update to v1.0.10

[abdonrd]

Describe the bug

In a Next.js v15 project, we are using gql.tada.
Currently the project is using the version 1.0.9 of @0no-co/graphql.web, and it's working fine!
But when we try to update to 1.0.10 (or 1.0.11), we get this error:

 ⨯ ReferenceError: e is not defined
    at Module.Kind (/Users/abdonrd/project-name/.next/server/chunks/ssr/node_modules_cb980b._.js:8254:18)
    at Kind (node_modules/gql.tada/src/api.ts:334:44)
    at [project]/src/components/CompetitionLogo.tsx [app-rsc] (ecmascript) (src/components/CompetitionLogo.tsx:7:47)
    at instantiateModule (/Users/abdonrd/project-name/.next/server/chunks/ssr/[turbopack]_runtime.js:589:23)
    at getOrInstantiateModuleFromParent (/Users/abdonrd/project-name/.next/server/chunks/ssr/[turbopack]_runtime.js:644:12)
    at esmImport (/Users/abdonrd/project-name/.next/server/chunks/ssr/[turbopack]_runtime.js:132:20)
    at [project]/src/app/(home)/data.ts [app-rsc] (ecmascript) (src/app/(home)/data.ts:3:0)
    at instantiateModule (/Users/abdonrd/project-name/.next/server/chunks/ssr/[turbopack]_runtime.js:589:23)
    at getOrInstantiateModuleFromParent (/Users/abdonrd/project-name/.next/server/chunks/ssr/[turbopack]_runtime.js:644:12)
    at esmImport (/Users/abdonrd/project-name/.next/server/chunks/ssr/[turbopack]_runtime.js:132:20)
    at [project]/.next-internal/server/app/(home)/page/actions.js { ACTIONS_MODULE0 => "[project]/src/app/(home)/data.ts [app-rsc] (ecmascript)" } [app-rsc] (ecmascript) <module evaluation> (/Users/abdonrd/project-name/.next/server/chunks/ssr/_89b741._.js:820:134)
    at instantiateModule (/Users/abdonrd/project-name/.next/server/chunks/ssr/[turbopack]_runtime.js:589:23)
    at getOrInstantiateModuleFromParent (/Users/abdonrd/project-name/.next/server/chunks/ssr/[turbopack]_runtime.js:644:12)
    at esmImport (/Users/abdonrd/project-name/.next/server/chunks/ssr/[turbopack]_runtime.js:132:20)
    at [project]/.next-internal/server/app/(home)/page/actions.js { ACTIONS_MODULE0 => "[project]/src/app/(home)/data.ts [app-rsc] (ecmascript)" } [app-rsc] (ecmascript) (/Users/abdonrd/project-name/.next/server/chunks/ssr/_89b741._.js:842:334)
    at instantiateModule (/Users/abdonrd/project-name/.next/server/chunks/ssr/[turbopack]_runtime.js:589:23)
    at instantiateRuntimeModule (/Users/abdonrd/project-name/.next/server/chunks/ssr/[turbopack]_runtime.js:652:12)
    at Object.getOrInstantiateRuntimeModule (/Users/abdonrd/project-name/.next/server/chunks/ssr/[turbopack]_runtime.js:668:12)
    at Object.<anonymous> (/Users/abdonrd/project-name/.next/server/app/(home)/page.js:16:9)
    at call (node_modules/next/src/server/require-hook.ts:70:25)
    at require (node_modules/next/src/server/require.ts:121:8)
    at page (node_modules/next/src/server/load-components.ts:189:41)
    at async DevServer.findPageComponentsImpl (node_modules/next/src/server/next-server.ts:779:27)
    at async DevServer.findPageComponents (node_modules/next/src/server/dev/next-dev-server.ts:881:13)
    at async DevServer.renderPageComponent (node_modules/next/src/server/base-server.ts:3584:19)
    at async DevServer.renderToResponseImpl (node_modules/next/src/server/base-server.ts:3659:23)
    at async DevServer.pipeImpl (node_modules/next/src/server/base-server.ts:1698:20)
    at async NextNodeServer.handleCatchallRenderRequest (node_modules/next/src/server/next-server.ts:1034:6)
    at async DevServer.handleRequestImpl (node_modules/next/src/server/base-server.ts:1462:8)
    at async (node_modules/next/src/server/dev/next-dev-server.ts:514:13)
    at async Span.traceAsyncFn (node_modules/next/src/trace/trace.ts:143:13)
    at async DevServer.handleRequest (node_modules/next/src/server/dev/next-dev-server.ts:512:19)
    at async invokeRender (node_modules/next/src/server/lib/router-server.ts:284:10)
    at async handleRequest (node_modules/next/src/server/lib/router-server.ts:530:15)
    at async requestHandlerImpl (node_modules/next/src/server/lib/router-server.ts:576:6)
    at async Server.requestListener (node_modules/next/src/server/lib/start-server.ts:146:6)
  332 |     let isFragment: boolean;
  333 |     if (
> 334 |       (isFragment = definitions[0].kind === Kind.FRAGMENT_DEFINITION) &&
      |                                            ^
  335 |       definitions[0].directives
  336 |     ) {
  337 |       definitions[0].directives = definitions[0].directives.filter( {
  page: '/'
}
 GET / 500 in 105ms

The component file has this fragment:

export const competitionLogoFragment = graphql(`
  fragment competitionLogoFields on competitions {
    name
    logo {
      id
    }
  }
`);

Meantime, we have this override in the package.json:

"overrides": {
  "@0no-co/graphql.web": "1.0.9"
}

Reproduction

TODO

Package version

@0no-co/graphql.web@1.0.10

Validations

• I can confirm that this is a bug report, and not a feature request, RFC, question, or discussion, for which GitHub Discussions should be used
• Follow our Code of Conduct

[kitten]

See: urql-graphql/urql#3704 (comment)
It's not an issue on our end and nothing we can do about it. You can examine the bundle, which should make it pretty clear that the bundle itself for graphql.web is fine.

[apostolos]

@kitten Please read this comment vercel/next.js#72232 (comment)

I think the bundler's behavior is correct (in assuming readonly properties shouldn't have setters). Please consider an alternative on your end.

[kitten]

@apostolos: This seems to imply that Turbopack attempts to use type-level information to alter the output code. I'm not saying this is wrong or not what's happening, but I find it unlikely and weird.

Making the assumption that just because some typing marks a property as readonly that it'll never be modifiable is simply incorrect. There are plenty of libraries and patterns out there that treat properties on user-facing types as readonly while still modifying them internally.

All of this of course completely ignores that loc was originally meant to be readonly

This isn't entirely correct either. While the property is marked as readonly, this is more of an artifact of the typings having been originally derived from Flow, which GraphQL.js used to be written in, but not a reflection of how that property is actually used.

Regardless, if an assumption here is made by bundlers, that doesn't really reflect the reality of all libraries.

Having a getter for a potentially undefined property causes problems, especially if you use "property is accessible" as an indicator for "property is assignable".

No, it doesn't inherently cause problems. That's an entirely different problem of whether a property is configurable and writable. We forgot the setter, and that was added, and I consider that a bug. Separately from that, it's always possible to construct objects with properties that aren't configurable or writable and cause errors. That's besides the point imho.

Something I have not fully understood yet is the entire graphql-tag situation

The underlying problem is pretty simple and unfortunate. graphql-tag has barely been updated and a long-standing issue it has it that assumes that node.loc will always be defined, which definitely doesn't reflect the reality of either graphql.js and other functions similar to it.

While I'd love to just ignore this problem, there's unfortunately many apps out there that still use graphql-tag (even when they maybe shouldn't) or mix graphql-tag into existing code bases, which causes these kinds of issues if we omit loc.

---

Anyway, more importantly:

• we can address this in @urql/core with a WeakMap cache instead, if it's actually an issue. However, that may cause more inter-compatibility issues with graphql-tag, since it reads loc, so it's basically coming back to the same issue potentially, but that might be less of a problem
• we need a specific reproduction or code here

As per the second point,

ReferenceError: e is not defined
at Module.Kind (/Users/abdonrd/project-name/.next/server/chunks/ssr/node_modules_cb980b._.js:8254:18)
Is an unrelated error of an entirely unrelated line, and we don't have a desymbolicated stack trace here.

So, what I'm lacking is:

• an error that shows what exactly is happening (this isn't a desymbolicated stack trace, so we're only working off of an error message here that implies Kind has been removed)
• an explanation of why Module.Kind is causing an error, which is unrelated to all the above
• code that shows the transformation (if it exists), since otherwise we don't know what our code is being changed into, and are working on shaky assumptions

Basically, if the above is happening, it's weird and unrelated to the error.
If the error is unrelated to the above, we don't have a way to figure out why it's happening.
If the issue with readonly occurs, we'd still have the issue of graphql-tag making an assumption, which limits the changes we can make.

So, from our end, I'm not sure there's anything here yet we can act on. Sorry 😅

Edit: Also, just to underline the point of not having enough information. This stood out to me from the linked comment:

when loc is defined, alter the properties of the existing Location instead of assigning a new Location to the originally readonly property. This would get rid of the (node as any) cast too.
This doesn't actually reflect what @urql/core is doing: https://github.com/urql-graphql/urql/blob/cf43315c40f9d40d963b401c1b505724154b552e/packages/core/src/utils/request.ts#L73-L83

We only add node.loc when it's missing, and don't need to update it. The problem is exactly the case where it's missing. Yes, @urql/core uses it for caching, but that's partially related to graphql-tag assuming it'll always be present.

[apostolos]

Thanks for the explanation @kitten. Do you mind if I share your response in the original Next.js thread, so the Turbopack people are more likely to read it?

[kitten]

I'm not sure it's relevant yet for the Next repo or Turbopack team per se. I assume, if this transformation is happening, it'd still be important for us to see what that transformation is
(as in, a desymbolicated stack trace or output code is still useful here). Because that allows us to see if or what's wrong and look at possible workarounds that still work for graphql-tag.

Other than that, the problem here is that we're now potentially working within the constraints of graphql-tag and Turbopack, if we can confirm what's wrong. It'd hence be useful to boil this down into a smaller piece of feedback (or an issue report) for the Turbopack team

[abdonrd]

Seems like they are working on a fix here:

• fix(turbopack): Use correct SyntaxContext for __turbopack_esm__ vercel/next.js#73544