Next.js: with-polyfills: Dynamic import of polyfill causes chunk load error

[jnv]

Examples bug report

Example name

with-polyfills

Describe the bug

with-polyfills shows how to polyfill missing features prior to initialization of Next app. However, I would like to load polyfills only for the missing features using the dynamic import.

For example IntersectionObserver is supported widely in the latest versions of browsers, so it's usually not necessary to load the intersection-observer polyfill. Thus I would like to import the polyfill only when the feature is missing like this:

// client/polyfills.js

async function loadPolyfills() {
  if (typeof window.IntersectionObserver === 'undefined') {
    await import('intersection-observer')
  }
}
export default loadPolyfills()

When I do that the application crashes when browser attempts to load the polyfill with the following error:

Unhandled Rejection (ChunkLoadError): Loading chunk 0 failed.
(error: http://localhost:3000/static/chunks/0.js)

Apparently Webpack points to the chunk in a wrong location, since the chunk is available in _next directory, i.e. http://localhost:3000/_next/static/chunks/0.js

To Reproduce

I have prepared a repository with reproduction of the issue. The feature detection is commented out to reproduce the behavior in any browser.

1. Download or clone https://github.com/jnv/next-with-polyfills-dynamic-import
2. Install dependencies with yarn
3. Start application with yarn dev
4. Go to http://localhost:3000/
5. See the error

Expected behavior

Browser loads the chunk without error, before Next initialization.

Screenshots

System information

• OS: macOS
• Browser: does not apply
• Version of Next.js: 9.0.2

[JackCA]

Has anyone found a workaround for this?

[jnv]

Yeah, I also wonder about that. We've ended up sourcing the polyfill from https://polyfill.io/ which is quite suboptimal.

[JackCA]

Yeah, not ideal. I just stopped dynamically importing it, as it was only 2KB gzipped.

I wonder if moving the dynamic import into another file that wraps it would help next.js resolve it better

[nickrttn]

I'm seeing the same thing. Using the same configuration as the with-polyfills example, I noticed that dynamic import() tries to load the script I added from a different path than other entries, causing a 404.

Loading the polyfills chunk

Loading another chunk

You can see that in the first screenshot, the /_next/ prefix is missing from the path.

[jnv]

I suspect that Next does some extra stuff with paths mapping either during or after the build and custom bundle entry point doesn't get transformed.

[mulholio]

This is quite a blocker for what I'm working on so I'm going to dive into the codebase and see if I can suggest a fix. Any time-saving recommendations of where to look appreciated!

[jnv]

@mulholio I've tried to find some leads in the codebase (e.g. references to _next/static/chunks directory etc.), but found only a few integration tests. Personally I'd start with build directory in the next package, and especially webpack-config. Creating an integration test from the example may be also helpful once you identify the source of this issue.

[mulholio]

I think this is actually something to do with Next Server which is what handles the _next prefix (source)

[mulholio]

This issue is of a very similar issue but no mention of what resolved it: https://github.com/zeit/next.js/issues/4993

[mulholio]

I've given up on this now but still very keen to see if anyone else comes up with a solution (anyone @zeit???)

[JackCA]

I'd remove the word "polyfill" from this issue because it seems to just flat out happen for dynamic imports. I am still continually hit by this

[jnv]

@JackCA Do you have any other examples where this happens? I ran into this specifically with modified Webpack config to run dynamic imports before Next.js initialization.

But when I think of it, I don't think we use import function anywhere outside of next/dynamic.

[JackCA]

This is happening for me when using a raw dynamic import of a library I don't want/need on the initial page load.

This doesn't happen to me for next/dynamic but as this isn't a React component that's being dynamically imported, I don't believe I can use that functionality.

Some additional context is that I'm seeing evidence that this is a "timeout" of some sort. Here is a public Sentry.io issue that may help.

[gfsd3v]

having the same issue, anybody have some info about this ?

[jnv]

FWIW I think the proposed plugins system could solve this if we can hook into the lifecycle before hydratation: https://github.com/vercel/next.js/discussions/9133