Layers make nuxt scan too many directories, if the layer has non app related sibling directories

[fabianwohlfart]

Environment

---

• Operating System: Darwin
• Node Version: v22.11.0
• Nuxt Version: 3.14.1592
• CLI Version: 3.16.0
• Nitro Version: 2.10.4
• Package Manager: npm@10.9.0
• Builder: -
• User Config: default
• Runtime Modules: -
• Build Modules: -

---

Reproduction

https://github.com/fabianwohlfart/test__nuxt-layers-slowdown

Describe the bug

I have a layer repo which is used by multiple websites.
It it located as a sibling / parallel to all the other website folders.

If I move this layer repo inside my website layer everything works as expected.

Development
- website-1
- - layer (works)
- website-2
- …

The moment I move it to a parent folder nuxt slows down with the warning

Development
- layer (slow)
- website-1
- website-2
- …

WARN Slow module imports took 10219.28ms to setup.

The moment I move it to my User folder the OS asks me for permission to access certain folders. That's why I assume that siblings are scanned too.

User
- Development
- layer (asks for permissions)
- Dokuments
- Images

As it is not possible for me to give you a reproduction with all my folders.
Yet I simplified it to a setup where we have one folder as a sibling with 250k js files.
If this folder exists it slows down nuxt significantly, but should not, as I don't expect it to be part of my app.

- app
- layer
- should-not-matter
- - [number].js (x 250000)

Without this folder

✔ Vite client built in 25ms
✔ Vite server built in 241ms
✔ Nuxt Nitro server built in 453 ms
ℹ Vite client warmed up in 0ms
ℹ Vite server warmed up in 308ms

With this folder

✔ Vite client built in 20ms                                                                                                  
✔ Vite server built in 172ms                                                                                             
✔ Nuxt Nitro server built in 1717 ms                                                                                 
ℹ Vite client warmed up in 1ms
ℹ Vite server warmed up in 325ms 

Original speed when my layer repo is a sibling of my website repos

 WARN  Slow module imports took 10219.28ms to setup.

ℹ Re-optimizing dependencies because lockfile has changed
✔ Vite client built in 26ms
✔ Vite server built in 348ms
✔ Nuxt Nitro server built in 20094 ms
ℹ Vite client warmed up in 0ms
ℹ Vite server warmed up in 440ms 

Additional context

No response

Logs

[Aareksio]

Since you pinged the nitro PR, this is the inline rollup plugin pi0 created, which counts number of resolved files during the build phase. If you suspect your issue has something to do with scanning unrelated files, it may help you confirm the theory. Furthermore you can modify it slightly to log the resolved path and look for something which shouldn't be there (usually node_modules):

  rollupConfig: {
    plugins: [
      (() => {
        let count = 0;
        const ids = new Set();
        return {
          name: "resolve-counter",
          resolveId(id) {
            ids.add(id);
            count++;
          },
          generateBundle() {
            console.log(
              `🚀 Total ${count} modules resolved, ${ids.size} unique`
            );
          },
        };
      })(),
    ],
  },

[fabianwohlfart]

Since you pinged the nitro PR, this is the inline rollup plugin pi0 created, which counts number of resolved files during the build phase. If you suspect your issue has something to do with scanning unrelated files, it may help you confirm the theory. Furthermore you can modify it slightly to log the resolved path and look for something which shouldn't be there (usually node_modules):

rollupConfig: {
plugins: [
(() => {
let count = 0;
const ids = new Set();
return {
name: "resolve-counter",
resolveId(id) {
ids.add(id);
count++;
},
generateBundle() {
console.log(
🚀 Total ${count} modules resolved, ${ids.size} unique
);
},
};
})(),
],
},

Maybe i was a bit too hasty on the ping.
I tried your plugin, but it logs modules after i get the slow modules import warning. So i guess it's not the right timing.

 WARN  Slow module imports took 11316.5ms to setup.                                                                                                                                                          

ℹ Building client...                                                                                                                                                                                    
ℹ vite v5.4.11 building for production...                                                                                                                                                                   
ℹ ✓ 419 modules transformed.                                                                                                                                                                               
rendering chunks (27)...
🚀 Total 17 modules resolved, 8 unique

[fabianwohlfart]

I tracked it down to the usage of scanDirExports: https://github.com/nuxt/nuxt/blob/main/packages/nuxt/src/imports/module.ts
The issue is resolved if we go back to unimport 3.13.4 – there was a switch to tinyglobby in 3.14.0, i (highly) suspect this as the cause

  "devDependencies": {
    "unimport": "3.13.4"
  },
  "overrides": {
    "unimport": "3.13.4"
  }

[davidstackio]

I'm also experiencing this issue. Downgrading unimport as @fabianwohlfart suggested worked for me.

This was the build time of my layer:

[fabianwohlfart]

I'm also experiencing this issue. Downgrading unimport as @fabianwohlfart suggested worked for me.

This was the build time of my layer:

Dev from tinyglobby got back to me.
@davidstackio You can use this, until they release the new version and dependents update.

"overrides": {
  "tinyglobby": "https://pkg.pr.new/tinyglobby@d51e2b9"
}

[davidstackio]

@fabianwohlfart Thanks! For my learning, what is the advantage of using the tinyglobby vs the unimport override?

[fabianwohlfart]

@davidstackio My take is that it's better to use a future version of something instead of locking into an old version.

[danielroe]

cc: @antfu

[antfu]

Linking to the upstream issue: SuperchupuDev/tinyglobby#77

Will update the deps when they release a stable new version