Dev Server Eagerly Compiles Dynamic Imports

[ddgromit]

Bug report

Describe the bug

The dev server is eagerly following dynamic imports in a page and compiling them before they are requested.

One of my pages does one of a few dynamic imports depending on the type of object its viewing. Each dynamic import in the page is reasonably sized but put together they cover almost the entire codebase. Since the dev server is compiling them all on the first page load, just to build that page (even before the page loads and can do the import) the dev server takes about 2-3 minutes of compilation time and node racks up over 4gb of memory.

The bundle chunks are actually generated correctly both in dev and production, and the code isn't actually loaded by the browser until the dynamic import is called. However it seems the dev server has to compile or process the entire tree of dynamic imports just to display the page for the first time.

To Reproduce

Requesting this page responds in seconds:

export default function TinyPage() { return <div>Hello</div>; }

Whereas this page takes minutes, even though the dynamic import is never called:

import dynamic from 'next/dynamic';
const SomeBigComponent = dynamic(() => import('./some-big-component'), { ssr: false });

export default function TinyPage() { return <div>Hello</div>; }

Expected behavior

Dynamically imported files should not be compiled by the dev server until the client requests them.

Screenshots

System information

• OS: mac
• Browser (if applies) chrome
• Version of Next.js: 9.5.5
• Version of Node.js: 12.13.1

[timneutkens]

This is how dynamic imports work in webpack unfortunately. cc @sokra

[ddgromit]

I was afraid of that. Any idea if Webpack 5 changes this behavior? I can't find anything that specifically references it in their changelog.

[awareness481]

Webpack will always compile dynamic imports at build time and that behavior will probably never change. On dev mode however the bundles are less optimized.

The name dynamic comes from the behavior of the imports, where the file is only imported on demand. In reality, there is not such thing as a dynamic export in Webpack (and probably most other bundlers). All exports are static, meaning they happen at build time.

[ddgromit]

It sounds like the only way to reduce load times is to reduce the amount of dynamic imports used by each page. I'll focus on splitting this very large page up into multiple smaller NextJS pages.

Thank you for your feedback! Closing this issue since the dev server load times are inherent to Webpack rather than NextJS.

[timneutkens]

Going to keep this open as we can potentially tackle it in the future.

[awareness481]

FWIW this seems to be on the roadmap for Webpack 5.

This webpack/webpack#8644 discussion has some interesting information. Including an npm package which I haven't tested, that defaults all dynamic imports to eager mode (no extra chunk). Obviously that should be used only for dev.

Ideally, if native support for webpackMode configuration is implemented that should be implementantion Next.js follows.

[ddgromit]

I don't think webpackMode: eager solves this issue.

Tagging an import as webpackMode: eager tells Webpack to always include the file in the current entry point rather than generate a separate chunk. Either way, Webpack is still parsing the dynamically imported file when the dev server starts.

The performance gains in the linked issue involve chunk-creation overhead, not the time necessary to actually parse the files that make up the chunk in the first place.

[github-actions]

Please verify that your issue can be recreated with next@canary.

Why was this issue marked with the please verify canary label?

We noticed the provided reproduction was using an older version of Next.js, instead of canary.

The canary version of Next.js ships daily and includes all features and fixes that have not been released to the stable version yet. You can think of canary as a public beta. Some issues may already be fixed in the canary version, so please verify that your issue reproduces by running npm install next@canary and test it in your project, using your reproduction steps.

If the issue does not reproduce with the canary version, then it has already been fixed and this issue can be closed.

How can I quickly verify if my issue has been fixed in canary?

The safest way is to install next@canary in your project and test it, but you can also search through closed Next.js issues for duplicates or check the Next.js releases.

My issue has been open for a long time, why do I need to verify canary now?

Next.js does not backport bug fixes to older versions of Next.js. Instead, we are trying to introduce only a minimal amount of breaking changes between major releases.

What happens if I don't verify against the canary version of Next.js?

An issue with the please verify canary that receives no meaningful activity (e.g. new comments that acknowledge verification against canary) will be automatically closed and locked after 30 days.

If your issue has not been resolved in that time and it has been closed/locked, please open a new issue, with the required reproduction, using next@canary.

I did not open this issue, but it is relevant to me, what can I do to help?

Anyone experiencing the same issue is welcome to provide a minimal reproduction following the above steps. Furthermore, you can upvote the issue using the 👍 reaction on the topmost comment (please do not comment "I have the same issue" without repro steps). Then, we can sort issues by votes to prioritize.

I think my reproduction is good enough, why aren't you looking into it quicker?

We look into every Next.js issue and constantly monitor open issues for new comments.

However, sometimes we might miss one or two due to the popularity/high traffic of the repository. We apologize, and kindly ask you to refrain from tagging core maintainers, as that will usually not result in increased priority.

Upvoting issues to show your interest will help us prioritize and address them as quickly as possible. That said, every issue is important to us, and if an issue gets closed by accident, we encourage you to open a new one linking to the old issue and we will look into it.

Useful Resources

• How to Contribute to Open Source (Next.js)
• How to create a Minimal, Complete, and Verifiable example
• Reporting a Next.js bug
• Next.js Triaging issues

[shehi]

Still happening (on latest Next 13.0.7 with classic pages setup, not app directory), something similar to this question on SO. It seemingly happens only on dev-env, causing worries. On dev, it only happens once when you first npm run dev. Consequitive attempts to replicate fail - the problem seemingly disappears.

Good question at this point is: Is it fixed with Turbopack? Or with the latest app directory of Next 13?

[jandylove]

same issue, how do you solve this now? @ddgromit