Dynamic import() fails in next 5.xx #3775
Comments
|
I've created reproducible test case https://github.com/aputinski/next-dynamic-import-test-case |
|
Thanks for the nice reproducible test case @aputinski. We'll take a look! |
|
@aputinski @lkostrowski We got this due to the the importing module is located inside the Like this: import React from 'react';
export default class extends React.Component {
static async getInitialProps() {
const post = await import('../lib/post.json')
return {
post
}
}
render () {
return <h1>{this.props.post.title}</h1>
}
} |
|
Hi guys, thanks for input. Unfortunately there must be at lease one more reason than @aputinski posted. So As I said before I have problem to reproduce it all the times I will do some checks today: |
|
Ok I have new input. However I detected how to accurately reproduce problem. It happens only after first server start (dev or prod), so it's enough to force server to build page again and chunks are built successfully. Even if I refresh page on another view and go to page with dynamic components, they are build well. Isn't it connected to server caching? I don't know what's happening under the hood, but looks like page is server before chunks created? Can I provide any more information? |
|
@arunoda Moving the file still produces the same error, but as @lkostrowski said, it only happens upon first starting the server. Refreshing the page or starting on that page results in no error. |
|
I've also tried giving the imported file a hard-coded chunk name using |
|
@arunoda If you can give me a few pointers on where to start, I can take a stab at debugging the issue. |
|
I am only experience this in dev-mode, and here its happening on each new route in the app:
Each route in my app has a dynamic require for the component used. Get the same error in the examples |
|
@gerhardsletten good that you mentioned that - just check and I also see this error on dev server |
|
I'm currently experiencing this on version |
|
Playing around with |
|
I'd also like to point out.. this bug only occurs during development.. the production build works fine with loading chunks. |
|
Anyone has a temporary solution ? |
|
I use With No SSR in development mode as a temporary solution const isDev = process.env.NODE_ENV !== 'production'
const PCSearch = dynamic(import('page/pc/index/Search'),{ ssr: !isDev }) |
|
@arunoda having this issue on Next 6, exact same behavior with the exception of ssr: false does not help. If i hit the route with a dynamic import directly all is fine. If i hit it as a routing even within the app it throws errors for every dynamic import:
|
|
Also be aware that errors are silenced in dynamic components with {ssr: false}. See #3009. I just encountered the error myself, and I have patched next to fix the silent error problem I mentioned above, so this is a separate issue. |
|
I am also running into this error getting I swapped it out for a raw NOTE: I'm using |
|
I'm curious if there is a way instead of trying to parse the import ourselves, if we could just pass off as much processing as possible to the import to webpack's Parser? That would probably allow dynamic imports with Computed module specifiers. |
|
After a couple hours of banging my head against the wall, I found that by using the multi-component example for Not the prettiest solution, but the api functions as expected and there are no more errors |
chunks to webpackManifest during development which fixes issue vercel#3775
|
I think this is the issue, these files should be static (unchanging) shouldn't they? I also notice that It is configured by the CommonsChunkPlugin here: server/build/webpack.js:302. The issue appears to be a race condition whereby a stale There is a line in the The reason You should find that reloading the page used If you look at @timneutkens @ptomasroos Would be great if you could shed light on how this is suppose to work. What does the comment I noticed that a chunkhash is appended to it in production...seeing as it is being recompiled constantly in development, maybe we need the chunkhas in dev too. Also, why are there two Also,
Also, if you manually set |
|
This issue will be fixed with webpack 4. |
|
@timneutkens When do you think this will be released in next? Weeks or months? Just wondering whether its worth me trying to find a fix for it. I am trying to disable the Okay so removing Disabling all commons chunks might fix it. Or finding a way to prevent the Commons chunk from churning between SSR webpack builds. I think the issue might be that because we are compiling server-side on each page navigation, this means the commons chunks are recompiled too, and the patch/on-demand chunks sent to the client are referencing the new commons chunks, that should be the same until the browser is refreshed. Tried disabling commons chunks but new issues arose. |
|
Dynamically importing modules in |
|
There is a workaround here: #4642 (comment) |
|
The workaround is not functional (or I'm implementing it wrongly). We've got: But the reference to the Flickity module still breaks. Note. The reason we're importing Flickity dynamically is because right now they instantly rely on |
|
The reason I'm saying it'll be solved when webpack 4 lands, is that I'm reworking the whole next/dynamic implementation so that it does nothing "special" and will just use default webpack Regarding a timeline, we'll release it whenever it's ready. I'm currently working on this. |
|
@mjanssen I just tried it out and it works. Try using: The idea with the workaround is to make sure that You can add the dynamic component imports to |
|
I moved the |
|
All right, so your fix works @vjpr, thanks. However, I've used the 'forbidden fruit' from React, to pass a So: Other solutions are welcome though ;) |
|
Found the cause webpack/webpack#4842 (comment). Webpack only adds the So when you visit a page directly which contains an import (somewhere in its dep graph), then you have the But if you visit a page directly that doesn't, then when you navigate to another page, it will compile a "non entry point" chunk and the When you visit the dynamic page though it will fail the first time, but the new Here is an example of both runtimes: https://gist.github.com/vjpr/a60945cd51068558a9b0cb2b744cef2f |
|
Going to re-open, I tried solving this yesterday with @vjpr but ran into more issues with |
|
I just installed the latest 8.1.0 version and it is still giving me error on dynamic import. |
|
It is weird, because |
|
Not sure how you ended up on an issue that is almost 1 year old and closed, has 28 participants that are being pinged etc. You're looking for #6240 I'm going to lock this issue as it was resolved to stop these people from being pinged 🙏. |
and others
I have been using this piece of code to asynchronously load one of heavy component on my client side. It was working like a charm:
const DynamicChart = dynamic( import('../components/LineChart/LineChart'), { loading: () => <SectionPlaceholder><Loader /></SectionPlaceholder>, ssr: false, }, );Since update to v5.0.0 I get webpack error, but only when I open the parent page from frontend route. When I directly load from server, it get's loaded. When I get it once (from first load) and go back to this page on frontend, it works too.
This is the error I get:
I tried
import(...).then(...).catch(...)but none of chains were triggered.The problem is that I can't reproduce it always.
I'm also using next-routes if that matters
I assume that problem occurs because of
undefinedpart in webpack. Any ideas how to debug the cause?My package dependencies:
Expected Behavior
Component gets loaded every time
Current Behavior
Sometimes component is not loaded and webpack tries to load something with
undefinedin nameThe text was updated successfully, but these errors were encountered: