The kit API, the build/runtime boundary, option channels, hooks, templates, testing and publishing.
Pages
- The mental modelWhat defineNuxtModule does with your definition, the three worlds a line of module code can live in, how Nuxt orders and deduplicates modules, and when onInstall and onUpgrade fire.
- The kit API, groupedThe @nuxt/kit helpers a module author should know from memory, grouped by what they do, with what each one does underneath and the source files worth reading.
- Crossing the boundaryThe four channels that carry a module option from the build world into the browser — public and private runtime config, appConfig and generated templates — and how to choose between them.
- Rules of the runtime directoryWhat src/runtime may and may not import, how module-builder transpiles it file by file, the .client/.server suffixes, and how to make Nitro inline your server runtime so
- HooksHow unjs/hookable powers the three hook families, a goal-to-hook cheat sheet for module authors, and how to declare your own hooks so other modules can cooperate with yours.
- Templates and typesGenerating code into .nuxt with addTemplate, adding declarations with addTypeTemplate, regenerating only your own templates on watch, and getting the nuxt/schema augmentation right.
- Dependencies and compositioninstallModule versus the declarative moduleDependencies field, detecting other modules with hasNuxtModule, choosing dependency versus peerDependency, and cooperating through hooks.
- Testing a moduleThe module test pyramid with @nuxt/test-utils — runtime unit tests, fixture E2E, build-level assertions, type tests, a nightly CI matrix and the non-functional tests a toolkit needs.
- Building, versioning and publishingWhat nuxt-module-build emits, the package.json fields that decide whether your module resolves, semver for modules, deprecating an option safely, and getting listed on nuxt.com/modules.
Notes for the whole section