Skip to content

docs: update module author guide#18551

Merged
danielroe merged 16 commits into
mainfrom
docs/module-author-guide
Mar 15, 2023
Merged

docs: update module author guide#18551
danielroe merged 16 commits into
mainfrom
docs/module-author-guide

Conversation

@atinux

@atinux atinux commented Jan 26, 2023

Copy link
Copy Markdown
Member

🔗 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

Preview URL: https://nuxt.com/docs/guide/going-further/modules?preview=26167363d40cf86d3af9a90dcbce0dee97fcb2a4032203da8d076c61fe15ef8a

📝 Checklist

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

@codesandbox

codesandbox Bot commented Jan 26, 2023

Copy link
Copy Markdown

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

@danielroe danielroe added the 3.x label Jan 28, 2023
@lihbr

lihbr commented Jan 29, 2023

Copy link
Copy Markdown
Member

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 outline

Intro to section

Quick Start

  • nuxi init
  • Next steps (basic commands, what to learn now)

Developing Modules

Basics

Explaining the basics briefly (maybe it's just part of the "next steps" in the quick start)

  • How to develop with the playground
  • How to build the module
  • How to publish it

Module Anatomy

Touring the directory structure

  • Module definition (defineNuxtModule)
  • Runtime directory
  • Playground directory

Tooling

Explaining the common tools used to author modules, just the big picture, not in depths

  • @nuxt/module-builder
  • @nuxt/kit
  • @nuxt/test-utils

Recipes

Sharing common patterns used to author modules (known as "Examples" today)

  • Exposing options to runtime
  • Injecting plugins with addPlugin
  • Injecting Vue components with addComponent
  • Inject other assets
  • Adding auto imports
  • Using hooks (+ module cleanup)

Testing

Sharing some testing strategies and how-tos

  • Unit & integration (mocking)
  • End to End (@nuxt/test-utils)
  • Manual QA with playground & externally

Best Practices

Quite 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"

Ecosystem

Presenting the ecosystem

  • Modules page on the doc / how to be listed
  • Official modules (@nuxt/*)
  • Community modules (@nuxtjs/*) / modules org on GitHub / how to join
  • Other community modules (nuxt-*) / maybe touching slighly on that people can make "personal" modules at their companies for various reasons and that that's a pattern
  • Contributing to the ecosystem (making it obvious anyone is welcome to improve existing modules)

Module internals

Maybe just a quick section touching on "how modules work" under the hood, priority, etc.

@danielroe danielroe added the 📚 documentation Documentation improvements or additions label Feb 2, 2023
@atinux

atinux commented Mar 7, 2023

Copy link
Copy Markdown
Member Author

Looks great for me @lihbr ❤️‍🔥

@lihbr lihbr marked this pull request as ready for review March 10, 2023 17:04
@lihbr

lihbr commented Mar 10, 2023

Copy link
Copy Markdown
Member

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!)~

Doc preview

image

@lihbr

lihbr commented Mar 11, 2023

Copy link
Copy Markdown
Member

Side thought: might be nice to add a recipe about adding a devtool tab, or maybe it's too early 🤔

@harlan-zw harlan-zw left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is really amazing work @lihbr!

I've added some ideas, feel free to ignore any that aren't relevant, reviewed this quite late 😅

Comment thread docs/2.guide/3.going-further/3.modules.md Outdated
Comment thread docs/2.guide/3.going-further/3.modules.md Outdated
Comment thread docs/2.guide/3.going-further/3.modules.md Outdated
Comment thread docs/2.guide/3.going-further/3.modules.md
Comment thread docs/2.guide/3.going-further/3.modules.md Outdated

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"`.

@harlan-zw harlan-zw Mar 13, 2023

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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? ☺️

Comment thread docs/2.guide/3.going-further/3.modules.md Outdated

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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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()
    })
  }
})

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, I get it but I'm not sure how to refactor that section to hint towards that, any suggestions? 🤔

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread docs/2.guide/3.going-further/3.modules.md
Comment thread docs/2.guide/3.going-further/3.modules.md
@lihbr

lihbr commented Mar 13, 2023

Copy link
Copy Markdown
Member

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 🎉

@atinux

atinux commented Mar 14, 2023

Copy link
Copy Markdown
Member Author

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!

Comment thread docs/2.guide/3.going-further/3.modules.md Outdated
Comment thread docs/2.guide/3.going-further/3.modules.md Outdated
Comment thread docs/2.guide/3.going-further/3.modules.md Outdated
Comment thread docs/2.guide/3.going-further/3.modules.md Outdated
lihbr and others added 4 commits March 14, 2023 19:09
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>
@danielroe danielroe merged commit e383d06 into main Mar 15, 2023
@danielroe danielroe deleted the docs/module-author-guide branch March 15, 2023 12:50

@danielroe danielroe left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Beautiful work all ❤️

@danielroe danielroe mentioned this pull request Mar 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

3.x 📚 documentation Documentation improvements or additions

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants