NextJs compiling extremely slow

I’ve experienced the issue with @mui/material and my own npm package @gorazdo/tomui The problem comes from a lot of modules to process (11k) like in this article Unfortunately, this solution doesn’t work. The problem is the regex (which is a completely mysterious thing for a non-rust developer. I’ve even tried Rust Regex online tool ), with no luck.

My Solution (3-5 times faster)

decreased 3-5 times dev build/rebuild/fast-refresh time decreased amount of modules by 10 times from 11k to 1k modules.

I’ve managed it using the following config:

    modularizeImports: {
      '@gorazdo/tomui': {
        transform: '@gorazdo/tomui/{{member}}',
      },
      '@mui/material': {
        transform: '@mui/material/{{member}}',
      },
      '@mui/icons-material/?(((\\w*)?/?)*)': {
        transform: '@mui/icons-material/{{ matches.[1] }}/{{member}}',
      },
    },

But I had to update imports manually for useTheme, ThemeProvider, styled, lighten and darken in my case

from:

import { Box, lighten, Typography, styled } from '@mui/material'
// for lighten and styled the regex didn't work neither the simple {{member}} way. so it is manually changed

to

import { Typography, Box } from '@mui/material'
import { styled, lighten } from '@mui/material/styles' 

To fix my library I had to use default export for each file which is going to be modularized.

Questions

1. How to deal with this regex to make it work with @mui/material ?
2. How to deal with modularization of files that have only named exports?
3. Can we automate modularization somehow?

Experiencing this issue?

To provide a trace which only includes metadata of the application:

• npm install next@canary (or yarn add next@canary)
• Run development like normal and reproduce the issue you’re experiencing
• Stop Next.js (generally ctrl + c)
• Send the file .next/trace file here or send it to https://twitter.com/timneutkens if you don’t want to share it publicly. You can use https://gist.github.com to create a private url for the file. - If you have a custom .babelrc please provide it - If you have a custom next.config.js please provide it - if you are using TailwindCSS please provide tailwind.config.js

⚠️ The metadata in .next/trace includes full file paths to all JS/CSS. It does not include the file contents. ⚠️ The main thing we need to help investigate your application is .next/trace, package.json and such are not helpful in investigating the issue.

Reply to earlier messages

but shouldn’t the potential solutions be posted here to help everyone that has this issue?

So far all I’ve done is help investigate the slowdowns for the people that reached out. There’s no specific solution as it highly depends on the app and I’m going to share the findings. . I’ve been working on a way that we can investigate these slowdowns without needing the application code itself but it requires a bunch of steps that up till a few days ago were quite involved.

Here’s a list of what I’ve found so far:

• @stevensturkop hasn’t provided a trace yet
• @PhillipLangMartinez
  • Fast Refresh is behaving as expected, no particular slowdown, will benefit from the work we’re doing for SWC and webpack optimizations though
  • The main problem they’re experiencing is about on-demand-entries. Next.js compiles the JS/CSS/etc for pages on-demand when you request them, so if you request http://localhost:3000/about Next.js will at that point start compiling the JS/CSS for pages/about.js, this is intentional to ensure that you can have thousands of pages in a Next.js app and it would not slow down your app, otherwise you’d pay this compilation penalty at bootup
    • This will also benefit from the work we’re doing integrating SWC with full backwards compat. I’ve had Phillip try the new flag and it’s resulted in at least 50% faster initial compilation and ~60% faster compiling of pages. Note that this highly depends on if you have a lot of node_modules or a lot of application code, the application code will be compiled faster but node_modules are not passed through babel currently so they are not affected by the work we’re doing to add SWC at this point in time.
  • In order to investigate this one further I’m adding timings for filesystem reads to find if that’s what is causing issues with a large amount of JS as they have a bunch of large node_modules like react-bootstrap included
• @kartikrao
  • 90% of the time spent compiling is related to TailwindCSS, it’s slowing down each CSS file by spending about 2 minutes and 30 seconds, it seems that the application is not using TailwindCSS JIT, so I’d recommend enabling that for all users that are using TailwindCSS: https://tailwindcss.com/docs/just-in-time-mode
• @f16z
  • Machine fs.readFile seems to be slow, it takes over 100ms per file, we expanded the tracing to include timing for individual files
  • Initial compile + compiling pages/index.js reads and compiles about 6867 files. What I’ve found is that 5557 of those are coming from @material-ui/icons/esm, assuming that the app is not using 5.5K icons I’d recommend changing how they are imported so that not all files have to be compiled. Based on debugging this trace we’re adding a separate chart that will allow us to visualize the dependency graph based on a trace file
• @billymcintosh can you provide a trace based on the above instructions