feat(nuxt): auto-register modules in ~/modules

[danielroe]

🔗 Linked issue

❓ 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

This adds support for scanning ~/modules and automatically registering any local modules there. The directory is configurable via dir.modules and supports local modules in layers.

It also adds support for automatically restarting Nuxt when these local module files are updated, resolving #12350. Note that at the moment, they are cached and a soft restart does not load an updated module - we should likely investigate the cause of this so we do not need a hard restart in this case.

📝 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

[pi0]

Nice idea! As a complement we might also introduce nuxt/kit since users have only nuxt dependency.

[Baroshem]

Awesome feature idea!

I can easily see using it in my projects :)

[Atinux]

I would like to update the behaviour to scanning ~/modules/<module-name>/module.ts so user can have the same structure as https://github.com/nuxt/starter/tree/module/src

Also, modules tends to include files so a directory is better for separation of concerns.

This way it's easier to extract when then want to publish their package to the Nuxt community

[Atinux]

Well actually I would prefer~/modules/<module-name>/index.ts which makes the most sense.

Why did we decide to go with module.ts on https://github.com/nuxt/starter/tree/module/src ?

[pi0]

For module builder package template, top-level index is reserved for util exports.

BTW for local scanning, {name}/{index,module}.ts seems a good idea since it is not a package with such reservations.

[Atinux]

I will try to keep it simple to modules/{name}/index.ts then 😊

Explaining to rename to module.ts when packaging in order to let them export utils makes perfect sense.

I guess we could also support top-level file for very simple modules?

[pi0]

I'm okay with either convention in local dir. Each has cons and pros.

[HigherOrderLogic]

I'm against this idea. Although auto registering modules inside ~/modules folder is convenient, not everytime the developer would want to load the modules in alphabetical order.

[pi0]

not everytime the developer would want to load the modules in alphabetical order.

I fully agree, and because of that, when you manually specify them in modules[] in configuration, they will be kept in your custom order.

[Atinux]

@HigherOrderLogic well you can do:

modules/
  1.c-module/
  2.d-module/

Similar to what we have in Nuxt Content for ordering links in the generated navigation.

[Atinux]

Might be worth adding to the docs?

[summer-0609]

How to ignore local modules that I don't want to be automatically registered

[danielroe]

You can use a different directory, nest them in a folder under ~/modules, or change dir.modules.

[ineshbose]

Regarding ordering, from the PR I understand that local modules load after nuxt.options.modules (maybe need to mention that in the docs) - is there a possibility to have one before (like the first loaded module possibly)? Not sure if adding the local module path to nuxt.options.modules could double-load it (if in dir.modules).

How to ignore local modules that I don't want to be automatically registered

We can also add functionality for prepending filename with . to ignore through a PR you think? 🙂

actually I would prefer~/modules//index.ts which makes the most sense.

The thing (for me at least) was to have consistent file-scanning in Nuxt (like #18418) because when the behaviour is different, it tends to confuse (me at least); though this PR has been long-released now. 😅

(Sorry for continuing the thread!)

[danielroe]

I think we already respect current ignore option when scanning modules.

And if local modules are added to nuxt.options.modules then they will run at that point and not be rerun later on (just like with nuxt.options.plugins.