Skip to content

Turbopack "unreachable code" string causing warnings in Firefox #74185

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
OleSkaar opened this issue Dec 20, 2024 · 5 comments · Fixed by #79703
Closed

Turbopack "unreachable code" string causing warnings in Firefox #74185

OleSkaar opened this issue Dec 20, 2024 · 5 comments · Fixed by #79703
Labels
linear: turbopack Confirmed issue that is tracked by the Turbopack team. Module Resolution Module resolution (CJS / ESM, module resolving). Turbopack Related to Turbopack with Next.js.

Comments

@OleSkaar
Copy link

OleSkaar commented Dec 20, 2024 •
edited
Loading

Link to the code that reproduces this issue

https://github.com/OleSkaar/with-turbopack-app

I've used the with-turbopack example here, with two dependencies that were giving the same error in my project:

"@tanstack/react-query": "5.62.2", "@tanstack/react-query-devtools": "5.62.2",

To Reproduce

  1. Start the application with pnpm run dev
  2. Open the app at localhost:3000
  3. Check the browser console in Firefox. You should see several warnings about unreachable code:

Screenshot 2024-12-20 at 12 59 10

This is happening because of the "TURBOPACK unreachable"; statement that's inserted after the return statement in the code from react query dev tools:

Screenshot 2024-12-20 at 12 49 38

Current vs. Expected behavior

I expect being able to load up this project without warnings in the console.

I believe Firefox is detecting the "TURBOPACK unreachable"; string as unreachable code and therefore reporting a warning (see this page).

The string appears before a function declaration, and this seemed to be the case for the other warnings reported here as well. This function is declared below the return the statement, but because of hoisting it is reachable (and used) higher up in the code. Could the "TURBOPACK unreachable"; string be inserted after the function declaration instead?

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.6.0: Mon Jul 29 21:14:30 PDT 2024; root:xnu-10063.141.2~1/RELEASE_ARM64_T6030
  Available memory (MB): 36864
  Available CPU cores: 12
Binaries:
  Node: 20.13.1
  npm: 10.5.2
  Yarn: 1.22.22
  pnpm: 9.14.4
Relevant Packages:
  next: 15.1.2 // Latest available version is detected (15.1.2).
  eslint-config-next: N/A
  react: 18.3.1
  react-dom: 18.3.1
  typescript: 5.7.2
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

Developer Experience, Module Resolution, Turbopack

Which stage(s) are affected? (Select all that apply)

next dev (local)

Additional context

No response
@OleSkaar OleSkaar added the bug Issue was opened via the bug report template. label Dec 20, 2024
@github-actions github-actions bot added Developer Experience Module Resolution Module resolution (CJS / ESM, module resolving). Turbopack Related to Turbopack with Next.js. labels Dec 20, 2024
@michaelwschultz
Copy link

It sure is and boy is it annoying. -unreachable filter works for now, but would love to see this fixed.

@henningsieh
Copy link

henningsieh commented Jan 4, 2025 •
edited
Loading

I do not know, if this is vercel or turbopack or trpc related to be honest, but I can confirm this.

grafik

.next/server/chunks/node_modules_@trpc_server_dist_1f68a9._.js

/**
 * Ponyfill for
 * [`AbortSignal.any`](https://developer.mozilla.org/en-US/docs/Web/API/AbortSignal/any_static).
 */ function abortSignalsAnyPonyfill(signals) {
    if (typeof AbortSignal.any === 'function') {
        return AbortSignal.any(signals);
    }
    const ac = new AbortController();
    for (const signal of signals){
        if (signal.aborted) {
            trigger();
            break;
        }
        signal.addEventListener('abort', trigger, {
            once: true
        });
    }
    return ac.signal;

    "TURBOPACK unreachable"; // <-- this line is unreachable
    function trigger() {
        ac.abort();
        for (const signal of signals){
            signal.removeEventListener('abort', trigger);
        }
    }
}
;
}}),

grafik

@OleSkaar
Copy link
Author

OleSkaar commented Jan 8, 2025

@michaelwschultz what is the -unreachable filter?

@michaelwschultz
Copy link

@michaelwschultz what is the -unreachable filter?

Adding this to your filter list in the browser output hides any message with "unreachable" in it so you can more easily ignore them.

@samcx samcx removed Developer Experience bug Issue was opened via the bug report template. labels Jan 22, 2025
@github-actions github-actions bot added the linear: turbopack Confirmed issue that is tracked by the Turbopack team. label Feb 3, 2025
@1hachem
Copy link

1hachem commented Feb 19, 2025

super annoying 🤕

@kdy1 kdy1 mentioned this issue May 27, 2025
Merged
kdy1 added a commit that referenced this issue May 27, 2025
@kdy1
fix(turbopack): Use comments instead of AST nodes for unreachables (#…
0ee8d5c 
…79703)

### What?

Use unreachable comments instead of AST nodes for statically analyzable unreachable AST nodes.

### Why?

It causes fewer problems for Firefox and potentially reduces RSS.

### How?

 - Closes PACK-3843
 - Closes #74185
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
linear: turbopack Confirmed issue that is tracked by the Turbopack team. Module Resolution Module resolution (CJS / ESM, module resolving). Turbopack Related to Turbopack with Next.js.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

fix(turbopack): Use comments instead of AST nodes for unreachables vercel/next.js
5 participants
@michaelwschultz @OleSkaar @samcx @henningsieh @1hachem