docs: update module author guide#18551
Conversation
|
|
|
Hey! Didn't get time to get fully to it this weekend. Since I'm pretty much off the coming week, I'll just share here the outline I had time to work on for now (still pretty rough, and consider headings wording WIP). If you have any feedback already, let me know, will pursue that work when I'm back~ Proposed outlineIntro to section Quick Start
Developing ModulesBasicsExplaining the basics briefly (maybe it's just part of the "next steps" in the quick start)
Module AnatomyTouring the directory structure
ToolingExplaining the common tools used to author modules, just the big picture, not in depths
RecipesSharing common patterns used to author modules (known as "Examples" today)
TestingSharing some testing strategies and how-tos
Best PracticesQuite similar to the current one, maybe I'd add a note on considering keeping the default (linter, etc.) so that public module code style all feels "alike" EcosystemPresenting the ecosystem
Module internalsMaybe just a quick section touching on "how modules work" under the hood, priority, etc. |
|
Looks great for me @lihbr ❤️🔥 |
|
Alright, I think it's getting pretty much ready for review, I'll likely tinker with it more over the weekend (already spent some time looking for typos) Any feedback is appreciated, I think some will likely want to play with heading levels. I'm pretty happy with the rework overall cc @atinux, also pinging @harlan-zw as I'm pretty sure you'll be insightful (but no pressure!)~ |
|
Side thought: might be nice to add a recipe about adding a devtool tab, or maybe it's too early 🤔 |
|
|
||
| Having a playground Nuxt application to test your module when developing it is really useful. [The module starter integrates one for that purpose](#how-to-develop). | ||
|
|
||
| You can test your module with other Nuxt applications (applications that are not part of your module repository) locally. To do so, you can use [`npm pack`](https://docs.npmjs.com/cli/v7/commands/npm-pack) command, or your package manager equivalent, to create a tarball from your module. Then in your test project, you can add your module to `package.json` packages as: `"my-module": "file:/path/to/tarball.tgz"`. |
There was a problem hiding this comment.
Not that important but most package managers provide link for this type of functionality which can be a bit more easier to work with when debugging, i.e npm link.
Alternatively just using a link in the package.json can be handy.
"my-module": "link:../modules/my-module"All good options though
(unrelated but could be worth mentioning stubbing nuxt-module-builder --stub)
There was a problem hiding this comment.
I thought about advertizing link here indeed, but I think there's a gotcha with using so (which would be why the current guide suggests pack), maybe @danielroe can enlighten us here?
|
|
||
| As we've seen, Nuxt Modules can be asynchronous. For example, you may want to develop a module that needs fetching some API or calling an async function. | ||
|
|
||
| However, be careful with asynchronous behaviors as Nuxt will wait for your module to setup before going to the next module and starting the development server, build process, etc. Prefer deferring time-consuming logic to Nuxt hooks. |
There was a problem hiding this comment.
Pointing people to use hooks is great but it kind of makes the problem worst as it's harder to debug when these things go wrong. Recommending logging around code that could take a while could help
import { useLogger, defineNuxtModule } from '@nuxt/kit'
export default defineNuxtModule({
setup (options, nuxt) {
const logger = useLogger('my-module')
nuxt.hook('modules:done', async () => {
logger.debug('Starting long async code')
await doSomethingThatTakesAWhile()
})
}
})There was a problem hiding this comment.
Hmm, I get it but I'm not sure how to refactor that section to hint towards that, any suggestions? 🤔
There was a problem hiding this comment.
Hm ye I agree it doesn't fit naturally. Maybe it's own section?
Providing Logs
It's good practice to provide logging within your module for code that could misbehave due to user configuration or environment. Allowing end-users to diagnose problems themselves as well as provide useful information for issues.
For example, imagine you're loading files from the user's file system when they are starting your module. The user can provide configuration to change which directories to scan.
If the user accidentally provides a path that is going to scan endless files (symlinked node_module, root directories), their nuxt app may hang indefinitely.
Or they may provide a directory that doesn't hang but is loading more files than expected, resulting in a significantly slower start.
import { useLogger, defineNuxtModule, resolveFiles } from '@nuxt/kit'
export default defineNuxtModule({
setup (options, nuxt) {
const logger = useLogger('my-module')
nuxt.hook('modules:done', async () => {
logger.debug('Loading files in ${loadDir}.')
const files = await resolveFiles(loadDir)
if (files.length > 1000) {
logger.warn(`Woah ${files.length} files, that's a lot! Is the ${options.loadDir} directory correct?`)
}
})
}
})To view debug logs users can run their Nuxt app with debug enabled
DEBUG=* nuxi dev.
When using other aspects of logging, you should avoid spamming the user with messages that don't provide any needed information.
|
Thank you so much for the review @harlan-zw! I agree with everything, will update in that direction Edit: handled most of the first reviews in babd24e, two remaining topics for discussion 🎉 |
|
This is an awesome work ❤️ IMO it is good to merge in the current state and we can always iterate to improve, this is already much better than the current one! |
Co-authored-by: Daniel Roe <daniel@roe.dev>
Co-authored-by: Daniel Roe <daniel@roe.dev>
Co-authored-by: Daniel Roe <daniel@roe.dev>
Co-authored-by: Daniel Roe <daniel@roe.dev>

🔗 Linked issue
❓ Type of change
📚 Description
Preview URL: https://nuxt.com/docs/guide/going-further/modules?preview=26167363d40cf86d3af9a90dcbce0dee97fcb2a4032203da8d076c61fe15ef8a
📝 Checklist