Nuxt Nitro server takes 1h to build (prod, Windows) - how to debug?

[pawelgur]

Medium sized project with Nuxt 3.10.3 with Nitro 2.9.6 and Vite 5.2.8.

When running nuxi build in SSR mode Building Nuxt Nitro server (preset: node-server) build step completes in around 6min on Linux machines.
When I try to run this locally on my Windows 10 machine it seems to be stuck forever - it took around 1h to build.

Client and server build steps are quick (~40s), building in SPA mode is quick too.

Unfortunately I can't share my project publicly.
Can someone share any tips how I can debug Nitro build step?

I've tried using env DEBUG=* which gives some debug info for previous build steps, but nothing for Nitro.

[pawelgur]

This seem to be somehow related to our custom nuxt modules (have 40+) as after removing all of them build is down to ~2min. Each module seem to add couple minutes of extra build time (some less, some more).

What I did so far is injecting custom rollup plugin for logging what's happening:

 rollupConfig.plugins.push({
      resolveId(id) {
        console.log('[TEST] Resolving module:', new Date().toISOString().slice(11, -1), id);
        return null; // Return null to defer to other resolvers
      },
    });

This has shown that majority of time is spent on module resolution, e.g.:

[TEST] Resolving module: 16:55:36.492 [...]/node_modules/nitropack/dist/runtime/entries/node-server
[TEST] Resolving module: 16:55:36.510 [...]\node_modules\nitropack\dist\runtime\entries\node-server.mjs
[TEST] Resolving module: 16:55:36.529 destr
[TEST] Resolving module: 16:55:36.529 h3
[TEST] Resolving module: 16:55:36.529 crossws/adapters/node
[TEST] Resolving module: 16:55:36.529 ../app.mjs
[TEST] Resolving module: 16:55:36.529 ../shutdown.mjs
[TEST] Resolving module: 16:55:36.529 ../utils.mjs
[TEST] Resolving module: 16:55:36.531 node:http
[TEST] Resolving module: 16:55:36.531 node:https
[TEST] Resolving module: 16:55:36.531 [...]/node_modules/nitropack/dist/runtime
[TEST] Resolving module: 16:55:36.533 unenv/runtime/mock/empty
[TEST] Resolving module: 16:55:36.558 [...]\node_modules\unenv\runtime\mock\empty.mjs
[TEST] Resolving module: 16:55:36.560 [...]\node_modules\nitropack\dist\runtime\utils.mjs
[TEST] Resolving module: 16:55:36.561 [...]\node_modules\nitropack\dist\runtime\app.mjs
[TEST] Resolving module: 16:55:36.563 [...]\node_modules\nitropack\dist\runtime\shutdown.mjs
[TEST] Resolving module: 16:55:36.574 h3
[TEST] Resolving module: 16:55:36.574 ./app.mjs
[TEST] Resolving module: 16:55:36.584 h3
[TEST] Resolving module: 16:55:36.585 ofetch
[TEST] Resolving module: 16:55:36.585 destr
[TEST] Resolving module: 16:55:36.585 unenv/runtime/fetch/index
[TEST] Resolving module: 16:55:36.585 hookable
[TEST] Resolving module: 16:55:36.585 ./config.mjs
[TEST] Resolving module: 16:55:36.585 ./cache.mjs
[TEST] Resolving module: 16:55:36.585 ./utils.mjs
[TEST] Resolving module: 16:55:36.585 ./route-rules.mjs
...

Same modules are being resolved multiple times (thousands?), each resolution takes few ms but due to sheer number of them all this piles up to many minutes.

[pawelgur]

Nitro uses rollup build programmatically, in order to debug build a custom rollup plugin with console.log's on different rollup hooks (as suggested here ) can be injected into rollup config.

Rollup perf option is a useful one, but it doesn't work out of the box with programmatic approach, thus rollup source node_modules/nitropack/dist/nitro.mjs has to be manually updated:

    // in _build function
    rollupConfig.perf = true; // enable timings
    const build2 = await rollup.rollup(rollupConfig).catch((error) => {
      nitro.logger.error(formatRollupError(error));
      throw error;
    });
    console.log(build2.getTimings()); // log perf timings

Same place can be used to inject logging plugin to rollupConfig.

Both these approaches didn't show clear cause of the issue, but gave some useful hints. Ended up removing rollup plugin by plugin to understand which one was taking most of the time that showed that nitro's node-externals was the issue.

Enabling legacyExternals resolved the issue (build finishes in 2min now).

Related: unjs/nitro#2369 unjs/nitro#2367