feat(kit, schema): measure module setup timings

[pi0]

🔗 Linked issue

resolves #15739

❓ Type of change

• 📖 Documentation (updates to the documentation or readme)
• 🐞 Bug fix (a non-breaking change that fixes an issue)
• 👌 Enhancement (improving an existing functionality like performance)
• ✨ New feature (a non-breaking change that adds functionality)
• ⚠️ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

• Adds new ModuleReturn interface for Nuxt modules with timings subkey
• Automatically measure kit-defined modules setup time and store in _installedModules
• [DX] Show a warning message if module takes more than 1 seconds to initialize

 WARN  Module test took 1502.4ms to setup!  

📝 Checklist

• I have linked an issue or discussion.
• I have updated the documentation accordingly.

[codesandbox]

  Open in CodeSandbox Web Editor | VS Code | VS Code Insiders

[Atinux]

It seems that using an anonymous module in the config does not trigger a warn:

export default defineNuxtConfig({
  modules: [
    async () => {
      // wait 2 sec
      await new Promise(resolve => setTimeout(resolve, 2000))
    }
  ]
})

I guess it's safe to ignore but we should advice to use @nuxt/kit to define Nuxt modules:

import { defineNuxtModule } from '@nuxt/kit'

export default defineNuxtConfig({
  modules: [
    defineNuxtModule({
      meta: {
        name: 'my-module'
      },
      async setup () {
        // wait 2 sec
        await new Promise(resolve => setTimeout(resolve, 2000))
      }
    })
  ]
})

[Atinux]

Looks good to me! Waiting for @danielroe review as well and @antfu regarding devtools integration

[manniL]

LGTM. Should we document it somewhere (besides auto-generated docs)?

[Atinux]

I guess in #18551

[harlan-zw]

PR looks good overall for timing. My two cents:

1. Utilise debug output

Consider the debug output atm.

Context is lost without knowing what module setup is taking place. It would be good to add a debug on the start of module setup and on the finish. There are a couple of modules that do globs and they have a habit of accidentally scanning the entire node_modules and stalling indefinitely. (pinceau, windicss, etc). Or making network requests which are using large timeouts.

2. Warning for slow modules

I think this just encourages module authors to "hide" logic that takes more than 1s within hooks, making it hard to debug, so I am against this (unless debug is enabled).

[Atinux]

Completely agree with you on this @harlan-zw

[danielroe]

@pi0 feel free to let me know if I can be helpful here 🙏

[pi0]

I have made a few changes. And also increased the minimum amount to 5 seconds which is unlikely to happen unless a module is doing something really wrong in which case, "end user" should be aware of why their development experience is slow. And also default hook logs, we have explicit module name as part of warning message so it is tracable.

I think anyway using this new exported meta devtools can give better experience. And we might try it for a while across ecosystem to first find the evil and decide to not warn if there are modules that absolutely cannot be optimized! But without a small push to the ecosystem and user awareness by testing against different environments, it is unlikely we could ever find those kind of modules.

[danielroe]

This approach seems good to me.

🚨 Note to readers: I think it is not too strong to say we are now engaged in a fight against evil across the galaxy. 🚨