feat: support modules to extend nitro builder

[Barbapapazes]

🔗 Linked issue

fix #1788

❓ Type of change

• 📖 Documentation (updates to the documentation, readme, or JSdoc annotations)
• 🐞 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)
• 🧹 Chore (updates to the build process or auxiliary tools and libraries)
• ⚠️ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

This PR introduce the concept of modules like in Nuxt.

• Support for function in the nitro.config file
• Support for function in the modules directory

This PR is a first implementation. depending of the usage, we will update the modules feature.

📝 Checklist

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

[pi0]

Thanks for picking up on it and nice you could take inspiration from the Nuxt module.

If you would like to work on your PR to be landed, i have added few comments to minify changes. Many of APIs and consideration in Nuxt happened over time and some based on legacy requirements we don't need to Nitro...

[Barbapapazes]

Thanks for picking up on it and nice you could take inspiration from the Nuxt module.

If you would like to work on your PR to be landed, i have added few comments to minify changes. Many of APIs and consideration in Nuxt happened over time and some based on legacy requirements we don't need to Nitro...

Thanks! 🪄

I update this PR a little and allow modules to be specify in a modules folder. Before continuing, I would like to know if I should specify how end-user will write a module. In Nuxt, there is the object meta and the nuxt-module-builder. Should we have the same thing? How could we improve the module implementation to have a better usage?

[pi0]

I expect as simple as this:

import type { NitroModule } from 'nitropack'
export default <NitroModule>{ async setup(nitro) {} }

Let's not keep ahead of ourselves. This feature is initially intended for advanced use cases not user-facing as Nuxt modules are until we can figure out use-cases :)

[codecov]

Codecov Report

Merging #1789 (b183043) into main (6c1570d) will decrease coverage by 0.11%.
The diff coverage is 47.43%.

@@            Coverage Diff             @@
##             main    #1789      +/-   ##
==========================================
- Coverage   52.38%   52.28%   -0.11%     
==========================================
  Files         170      172       +2     
  Lines       11806    11882      +76     
  Branches      910      908       -2     
==========================================
+ Hits         6185     6212      +27     
- Misses       5525     5573      +48     
- Partials       96       97       +1     

Files	Coverage Δ
src/build.ts	83.80% <100.00%> (+0.02%)	⬆️
src/scan.ts	100.00% <100.00%> (ø)
src/types/index.ts	100.00% <100.00%> (ø)
src/types/module.ts	100.00% <100.00%> (ø)
src/types/nitro.ts	100.00% <100.00%> (ø)
src/nitro.ts	82.48% <60.00%> (-4.08%)	⬇️
src/module.ts	17.50% <17.50%> (ø)

... and 2 files with indirect coverage changes

[Barbapapazes]

I expect as simple as this:

import type { NitroModule } from 'nitropack'
export default <NitroModule>{ async setup(nitro) {} }

Let's not keep ahead of ourselves. This feature is initially intended for advanced use cases not user-facing as Nuxt modules are until we can figure out use-cases :)

So I think this PR is ready for a review!