Nuxt•2w ago

Module authoring with tsup

When authoring a Nuxt module, it is recommended to use this template which uses @nuxt/module-builder under the hood. What if you don't want to use it, and you're using something like bunchee or tsup, is it still possible? I attached a code example, and just want clarification if it's safe to use. You would normally import it via #imports if using @nuxt/module-builder, but this time since Im using a different bundler, is it safe? Also, can we skip CJS build today when authoring a module if your package dont rely on any commonjs package? Thank you Nuxt team!

GitHub

GitHub - nuxt/starter: Create a new Nuxt project, module, layer or ...

Create a new Nuxt project, module, layer or start from a theme with our collection of starters. - nuxt/starter

2 Replies

kapa.ai•2w ago

Hi @TheSadMidDeveloper. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave: ---------------------- Thank you for your question about Nuxt module authoring. I'll address your points based on the information provided in the knowledge sources. 1. Using alternative bundlers: While the Nuxt module template (https://nuxt.com/docs/community/contribution#conventions-across-ecosystem) is recommended, it's not strictly required. You can use alternative bundlers like bunchee or tsup for module authoring. However, it's important to ensure that your module follows the necessary conventions and can be properly integrated into the Nuxt ecosystem. 2. Importing from #imports: The #imports alias is specifically used for auto-imports in Nuxt applications, not for module authoring. When creating a module, you should use explicit imports from the appropriate Nuxt packages. For example, you can import from @nuxt/kit for module-related utilities:

import { defineNuxtModule, addImports, createResolver } from '@nuxt/kit'

import { defineNuxtModule, addImports, createResolver } from '@nuxt/kit'

This approach is demonstrated in the auto-imports example (https://nuxt.com/docs/api/kit/autoimports#examples) from the Nuxt documentation. 3. Skipping CJS build: Regarding skipping the CommonJS (CJS) build, it's becoming increasingly possible to use ESM-only modules. However, there are some considerations: - Nuxt and the broader Node.js ecosystem are transitioning towards ESM, but there's still significant CJS usage. - If your module doesn't rely on any CommonJS packages and is intended for Nuxt 3 (which supports ESM), you could potentially skip the CJS build. However, the Library Author Guide (https://nuxt.com/docs/guide/concepts/esm#library-author-guide) recommends: 1. Renaming your ESM files to end with .mjs (recommended and simplest approach). 2. Optionally, making your entire library ESM-only by setting "type": "module" in your package.json. The guide also suggests using the exports field in package.json with conditional exports:

{
  "exports": {
    ".": {
      "import": "./dist/mymodule.mjs"
    }
  }
}

{
  "exports": {
    ".": {
      "import": "./dist/mymodule.mjs"
    }
  }
}

This approach allows you to specify ESM-specific entry points for your module. In conclusion, while it's possible to use alternative bundlers and potentially skip CJS builds, it's important to ensure your module remains compatible with the Nuxt ecosystem and follows best practices for ESM compatibility. Always test thoroughly to ensure your module works as expected in various Nuxt project configurations. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------

kapa.ai•2w ago

<@1214688654199496797> Kapa.ai is still learning and improving, please let me know how I did by reacting below.

Gaming

Programming

Module authoring with tsup