[NEXT-847] ChunkLoadError only on deployement if using next/dynamic since Next 13.2.4

[Timothee-P]

Verify canary release

• I verified that the issue exists in the latest Next.js canary release

Provide environment information

Operating System:
      Platform: darwin
      Arch: arm64
      Version: Darwin Kernel Version 22.3.0: Mon Jan 30 20:39:35 PST 2023; root:xnu-8792.81.3~2/RELEASE_ARM64_T8103
    Binaries:
      Node: 18.12.1
      npm: 8.19.2
      Yarn: 1.22.19
      pnpm: 7.29.0
    Relevant packages:
      next: 13.2.5-canary.4
      eslint-config-next: 13.2.4
      react: 18.2.0
      react-dom: 18.2.0

Which area(s) of Next.js are affected? (leave empty if unsure)

App directory (appDir: true), Dynamic imports (next/dynamic)

To Reproduce

I'm working on trying to reproduce this bug with the reproduction-template, but haven't been able till now.
Maybe creating a exemple with multiple chunks will make it work?

Describe the Bug

Since upgrading next from 13.2.3 to 13.2.4, I have a chunkLoadError on my /app pages, which cause hydratation error.
This only occurs on Vercel deployment or after running next build && next start.
No errors/warning if using next dev or during the build.

Here is a screenshot of the errors:

After investigation, the issue seam to appear if using dynamic imports via next/dynamic(or React.lazy).
Dynamic import seem to break hydration when importing component with sub-components also used outside the import.
No issue with a simple 'Hello world' dynamic import, or if bypassing next/dynamic on these more complexe components.

Also, in the exemple showed via the screenshot, the file 3845-003ea1aae1221d6c.js doesn't exist in the /.next folder. But .next/static/chunks/3845.a2edb05c0b138330.js does.

Apparently the same error occurred for jinojacob15 (Comment-#46989) and SuttonJack (Comment-#46989), which seems unrelated to the initial issue.

Expected Behavior

No error on deployement, or at least printing an error on next dev or next build

_NEXT-847

[jinojacob15]

Faced the same issue

[miriyas]

Same here, client-reference-manifest is pointing wrong file.

830-004c10da4a4c61af.js exist, but manifest sees like 830-s0meth1ngwr0ng.js.

When I removed all dynamic imports, problem gone.

[AndreSilva1993]

Facing the same thing. I have one page being dynamically loaded - using next/dynamic - since it uses the Leaflet library (which tries to access the window object immediately) and it causes this error in a completely different page. If I remove that dynamic import, everything works as expected.

For reproduction cases, if you want, you can use my personal website's source code which is open source - https://github.com/AndreSilva1993/personal-website. After building and running next start, this error occurs on the homepage every time.

[ecomperftest]

I am facing the same issue too

[jerray]

Facing the same issue on 13.3.0

[Nickman87]

Also have the same issue, even in the latest canary 13.3.1-canary.8.
It is not so easy to reproduce it seems as I tried to make a codesandbox, but it just works, so there will be more at play that just a single next/dynamic import.
https://codesandbox.io/p/sandbox/jovial-bogdan-dv2vkl

I currently bypassed it by doing this (just so it does not render serverside):

// import dynamic from "next/dynamic";
// const App = dynamic(() => import("@/admin/App"), { ssr: false });

const Admin: NextPage = () => {
  if (window) {
    const App = require("@/admin/App").default;
    return <App />;
  }

  return null;
};

[miriyas]

next@13.3.1-canary.14

Same

[miriyas]

next@v13.3.1-canary.16

Confirmed fixed, thanks!

[Nickman87]

Yes, everything works as expected now, thanks!

[github-actions]

This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.