ReferenceError: e is not defined error occurs when running next dev --turbo #72232
Comments
|
In the 15.0.2 version --turbo command has replaced to --turbopack #71730 |
|
The same issue occurs with the --turbopack command as well. |
|
I'm getting the same error with I think the problem is related to If I pin One of the following PRs is introducing the problem: |
timneutkens
added
the
linear: turbopack
|
Through bisection i figured out that it's a problem with Specifically these five lines that introduce a setter cause the problem. Removing those lines even in the current master branch HEAD of the /0no-co/graphql.web project and building the project results in a I assume the broader problem is that the document function returns ast.DocumentNode, which in turn uses a custom Or type to express that it's either their own DocumentNode or a DocumentNode from graphql-js. Both of those DocumentNode have an optional property The combination of getter and setter existing for an (optional) property that is otherwise never used, in combination witth the getter and setter not referring to the actual property of ast.DocumentNode is probably something Turbopack can't handle. |
|
Alright, looked into this some more. I'll summarize my findings and then we can maybe discuss where this should be reported, since I don't believe it's something that Turbopack can fix/should attempt to fix. I'll be referring to the following code snippets (all links are permanent links to the current head-commits on their respective master/main branch, as of writing this):
This IMHO is a flawed function, because it assumes there is a place in the It worked until it did not work anymore: This pull request added a getter to Having a getter for a potentially undefined property causes problems, especially if you use "property is accessible" as an indicator for "property is assignable". And so it crashed, resulting in this gql.tada issue, where the stacktrace indicates that it crashed exactly in All of this of course completely ignores that Anyways, instead of overthinking this entire situation adding a setter was the chosen solution that worked for them, but that now just propagates the issue to turbopack users. Turbopack (rightfully) assumes How I would fix this problem: roll back the introduction of the setter and getter and improve the stringify method in two ways:
Something I have not fully understood yet is the entire Overall there are A LOT of parties/people involved in this entire situation and turbopack users are simply on the receiving end of an unfortunate situation. Following the chain of dependencies I believe a good place to start would be reporting the problem to urql, who could then decide whether this is something they would want to improve. This time it's turbopack, but next time it could be some other dependency/project that runs into trouble with urql. Reporting an issue to urql involves creating a reproduction, which I wouldn't mind doing but I first wanted to hear the opinions of other people here. |
|
I just ran into this with |
|
This is really weird. I'm also having this same issue with @0no-co/graphql.web It seems the following code from node_modules/@0no-co/graphql.web/dist/graphql.web.mjs: var e = {
NAME: "Name",
DOCUMENT: "Document",
... etc ...
};
export { c as BREAK, GraphQLError, e as Kind, ... etc ... };Transpiled file .next/server/chunks/ssr/node_modules_d78758._.js: __turbopack_esm__({
"BREAK": (()=>c),
"GraphQLError": (()=>GraphQLError),
"Kind": (()=>e),
... etc ...
});
var e1 = {
NAME: "Name",
DOCUMENT: "Document",
... etc ...
};As you can see, "Kind" referes to the var When I change the var name in .next/server/chunks/ssr/node_modules_d78758._.js: __turbopack_esm__({
"BREAK": (()=>c),
"GraphQLError": (()=>GraphQLError),
"Kind": (()=>foo),
... etc ...
});
var foo = {
NAME: "Name",
DOCUMENT: "Document",
... etc ...
};It seems that there might be a bug in fixing name collisions during transpilation? |
|
Only the esm export of @0no-co/graphql.web has the issue above. Is there a way to force turbopack to choose the cjs output for a package? The only way I get it working is via the patch below (using https://www.npmjs.com/package/patch-package): diff --git a/node_modules/@0no-co/graphql.web/package.json b/node_modules/@0no-co/graphql.web/package.json
index bd060d6..99b7d28 100644
--- a/node_modules/@0no-co/graphql.web/package.json
+++ b/node_modules/@0no-co/graphql.web/package.json
@@ -16,8 +16,7 @@
"exports": {
".": {
"types": "./dist/graphql.web.d.ts",
- "import": "./dist/graphql.web.mjs",
- "require": "./dist/graphql.web.js",
+ "default": "./dist/graphql.web.js",
"source": "./src/index.ts"
},
"./package.json": "./package.json"
|
|
@nphmuller Thank you so much for the investigation! |
This comment has been minimized.
This comment has been minimized.
|
Well, I'm on vacation until 1/1 |
This comment has been minimized.
This comment has been minimized.
|
I'll work on this issue (and swc/turbopack bufixes) starting from the tomorrow. |
This comment has been minimized.
This comment has been minimized.
|
Would love to help or get this fixed! |
|
Any guidelines for how contributors can help fix this? My team is really wanting to make some progress here, we're happy to help in whatever way that we can. |
|
@tylerslaton You would need to define |
|
@kdy1 I see that this Draft PR points to this issue (72232). Is it planned to be merged? |
|
To add some color here, this is impacting any package that uses either of those Furthermore It seems that if users previously picked But e.g. any first-time Next.js user (or a user on a new machine) will see broken behavior on the default path for lots of packages. |
Link to the code that reproduces this issue
https://github.com/y-hsgw/with-urql
To Reproduce
When using
next dev --turbowith a Next.js application, the following error message appears:ReferenceError: e is not defined at Module.Kind (/path/to/.next/server/chunks/ssr/node_modules_xyz.js:1376:18) at Kind (turbopack://[project]/node_modules/@urql/core/src/gql.ts:84:30) ...The application works without issues when running the
next devcommand.Current vs. Expected behavior
bug screenshot:
Provide environment information
Operating System: Platform: darwin Arch: arm64 Version: Darwin Kernel Version 24.0.0: Tue Sep 24 23:36:26 PDT 2024; root:xnu-11215.1.12~1/RELEASE_ARM64_T8103 Available memory (MB): 8192 Available CPU cores: 8 Binaries: Node: 22.10.0 npm: 10.9.0 Yarn: 4.5.1 pnpm: N/A Relevant Packages: next: 15.0.2 // Latest available version is detected (15.0.2). eslint-config-next: N/A react: 18.3.1 react-dom: 18.3.1 typescript: 5.6.3 Next.js Config: output: N/AWhich area(s) are affected? (Select all that apply)
Turbopack
Which stage(s) are affected? (Select all that apply)
next dev (local)
Additional context
I also submitted an issue to urql, but they responded that it was an issue on the Next.js side.
urql-graphql/urql#3704
The text was updated successfully, but these errors were encountered: