rollup error module nuxt 4
Im trying to update my module (https://github.com/Pentadome/nuxt-openAPI-wrapper/tree/nuxt-4) to Nuxt 4. but after updating, whenever i build the playground, i get this rollup error:
Do i need to do something special to get typescript support for nuxt 4 modules?
GitHub
GitHub - Pentadome/nuxt-openAPI-wrapper at nuxt-4
Generates a typesafe fetch client for Nuxt using Openapi-ts. - GitHub - Pentadome/nuxt-openAPI-wrapper at nuxt-4
21 Replies
Hi @Zoidberg. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
This error happens because Rollup (used by Nitro during build) is trying to parse a .ts file that only contains a type-only export, which isn’t valid at runtime. In Nuxt 4, type support is split into multiple tsconfig contexts and auto-import/type generation changed, so modules must avoid emitting type-only re-exports into runtime bundles.
What to do:
- Don’t import or reference .ts files that only export types from runtime paths. Move shared types to a shared/types (or app/types) location that’s included in Nuxt’s shared TS context, and consume them via types only (no runtime import). Nuxt 4 generates .nuxt/tsconfig.shared.json and related typings for this purpose (TypeScript Configuration Splitting; Auto-generated Types).
- If you previously relied on auto-importing types from a root types folder, ensure those files are resolved relative to srcDir (app/ by default in Nuxt 4), or use aliases like ~/types. Prefer shared/ for types used on both server and client (Auto-import types from "types" directory breaks…).
- As a module author, ensure your module’s runtime output only contains runtime-safe code (no type-only exports). Nuxt modules are build-time-only; use @nuxt/kit to add templates/plugins, and keep type-only utilities in type declaration files or shared context, not emitted JS (Modules migration; Module migration guide).
Concretely for your error line:
- Replace export type * from '.../fetchTypes' in any file that ends up in .nuxt/openapi-wrapper/* with either:
- A .d.ts declaration file (not imported at runtime), or
- Keep the types in shared/types and reference them via type-only imports inside TS code, without re-exporting them from runtime templates/plugins.
If you need template code-gen changes (from old EJS), follow the Nuxt 4 template compilation migration to avoid bringing type-only exports into generated files (Template Compilation Changes).
If issues persist, enable proper TS project refs (npx nuxt prepare; use .nuxt/tsconfig.*.json) and ensure your module’s entry added in modules points to its index file (not just the folder) (Configuration migration: Modules; Auto-generated Types).
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
<@189706998231728128> Kapa.ai is still learning and improving, please let me know how I did by reacting below.
@kapa.ai where does it say that modules should also use a shared folder?
Let me check the knowledge base for you again. One moment! :books:
----------------------
The docs don’t say that “modules should also use a shared folder.” The shared/ directory is documented for application code to share between app and server, with auto-import behavior and TS setup, but nothing in the provided sources mandates using shared/ inside modules. If you’re authoring a module, Nuxt 4 notes that modules are build-time-only and you should point to the module entry file, but it doesn’t prescribe using shared/ for modules (Modules migration). The shared directory itself is documented for apps, not module internals (shared directory). TypeScript project references and augmentation guidance also target app/server/shared contexts of the consuming project, not module code (TypeScript config splitting; Augmenting types with project references).
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
<@189706998231728128> Kapa.ai is still learning and improving, please let me know how I did by reacting below.
@kapa.ai that modules migration is about nuxt 2 to 3.. i need help about 3 to 4
Let me check the knowledge base for you again. One moment! :books:
----------------------
You’re right—the “Modules migration” page you were linked is about Nuxt 2 → 3 and doesn’t state anything specific for Nuxt 3 → 4 regarding using a shared folder inside a module.
For Nuxt 3 → 4, the documented change is TypeScript configuration splitting for applications, introducing app/server/shared-specific tsconfig files. Guidance to place shared type augmentations in shared/ applies to app code in the consuming project, not to module internals (TypeScript Configuration Splitting; Migration Steps). There’s no statement in the Nuxt 4 docs that modules themselves must use a shared/ directory.
The only relevant mention to your earlier issue is that auto-imported types/dirs are now resolved relative to srcDir (app/ by default in Nuxt 4) and that shared/ is recommended for types shared between client and server in the app. This came up in a GitHub issue discussion, not as an official module requirement (Issue 32870).
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
<@189706998231728128> Kapa.ai is still learning and improving, please let me know how I did by reacting below.
@kapa.ai
As a module author, ensure your module’s runtime output only contains runtime-safe code (no type-only exports).
where do the docs say this?Let me check the knowledge base for you again. One moment! :books:
----------------------
I can’t find a place in the provided Nuxt 4 docs that explicitly says “ensure your module’s runtime output only contains runtime-safe code (no type-only exports).” The closest guidance is:
- Nuxt modules are build-time-only in Nuxt 4; they don’t participate in the application runtime. Use modules to alter build/config and inject runtime assets (plugins, components, server routes) via the runtime directory, but don’t rely on sharing state/code between build and runtime (Modules concept, Modules are build-time-only, Runtime vs build context).
- When exposing module options to runtime, use runtimeConfig; avoid leaking sensitive config to public runtime. This implies keeping runtime payloads to runtime-usable code/data only (Exposing options to runtime, Runtime Config).
- Module author best practices emphasize ESM-only code and avoiding CJS/globals, but they don’t mention type-only exports specifically (Best practices, ESM guide). So, there’s no explicit line about “no type-only exports” in module runtime output in these sources; the recommendation follows from modules being build-time-only and from the separation between build and runtime contexts. If you need stricter guidance, the docs don’t state it verbatim. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------
- When exposing module options to runtime, use runtimeConfig; avoid leaking sensitive config to public runtime. This implies keeping runtime payloads to runtime-usable code/data only (Exposing options to runtime, Runtime Config).
- Module author best practices emphasize ESM-only code and avoiding CJS/globals, but they don’t mention type-only exports specifically (Best practices, ESM guide). So, there’s no explicit line about “no type-only exports” in module runtime output in these sources; the recommendation follows from modules being build-time-only and from the separation between build and runtime contexts. If you need stricter guidance, the docs don’t state it verbatim. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ----------------------
<@189706998231728128> Kapa.ai is still learning and improving, please let me know how I did by reacting below.
@kapa.ai but it worked in nuxt 3. Has any guidance about this changed?
Let me check the knowledge base for you again. One moment! :books:
----------------------
Short answer: there’s no explicit Nuxt 4 “module author” guidance stating a new rule about type-only exports. What changed is Nuxt 4’s TypeScript setup and generated typings, plus stricter separation of build/runtime contexts. That can surface cases where a generated runtime file ends up containing a type-only export, which Rollup can’t bundle.
Relevant changes:
- Nuxt 4 introduced TypeScript configuration splitting with separate app/server/shared/node tsconfigs and project references. This affects how and where types are recognized, but apps remain backward compatible unless you opt in to references (TypeScript configuration splitting; Migration steps).
- Runtime vs build context separation is emphasized: production builds are standalone and independent of nuxt.config/modules, reinforcing that runtime code must be runtime-safe (Runtime vs build context).
- Some experimental toggles were removed, but nothing about type-only exports in modules (Removal of experimental features).
So, while it may have “worked” in Nuxt 3, the Nuxt 4 TS/typing generation and stricter contexts can expose issues where a template/generated file ends up with export type ... in a runtime bundle. The docs do not state a new rule; the observed breakage is a consequence of these changes rather than an explicitly documented policy change.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
<@189706998231728128> Kapa.ai is still learning and improving, please let me know how I did by reacting below.
the difference is probably that the build directory is now in node_modules by default
try removing
.nuxt and rebuilding and seeing if it works (it should then use .nuxt as buildDir instead)hmmm... I tried that but now i get
[vite:esbuild] failed to resolve "extends":"./.nuxt/tsconfig.json" in C:\Users\user\repos\nuxt-open-api\nuxt-openapi-wrapper\tsconfig.json
The tsconfig file is the same as in the started template (https://github.com/nuxt/starter/blob/module/tsconfig.json)GitHub
starter/tsconfig.json at module · nuxt/starter
Create a new Nuxt project, module, layer or start from a theme with our collection of starters. - nuxt/starter
@kapa.ai any ideas?
Let me check the knowledge base for you again. One moment! :books:
----------------------
A few concrete fixes you can try, based on the docs:
- Ensure your module doesn’t emit type-only exports into runtime code. If a generated file under .nuxt/openapi-wrapper/* contains export type ..., change your template/plugin generation so that:
- types live in a .d.ts file added via addTypeTemplate (which Nuxt will reference in nuxt.d.ts), not in a runtime .ts file (Adding type declarations).
- or you keep type imports inside TS code but don’t re-export them from runtime files.
- Keep your module ESM-only and avoid CJS. If you hit ESM interop problems with dependencies during the build, consider transpiling or aliasing problematic packages in the host app’s nuxt.config as a workaround (Troubleshooting ESM issues).
- Build the module with @nuxt/module-builder so the output is compatible with Nuxt apps. This helps ensure your published artifacts are correctly shaped for Nuxt’s build pipeline (@nuxt/module-builder).
- If you need to expose options or utilities to the runtime, write actual runtime plugins/components via @nuxt/kit (addPlugin/addComponent) and put pure types behind runtimeConfig or in declaration files rather than exporting type-only entries from runtime modules (Altering config, exposing options, addPlugin/addComponent).
- Verify your module is added via its entry file and that you’re not pointing to a directory (Nuxt 4 expects modules to be build-time-only and referenced by entry) (Migration: Modules).
- If the error originates from importing a TS file directly in Nitro/Rollup that only contains types, remove that import (it has no runtime value) or convert it to a .d.ts added via addTypeTemplate as above. Rollup will error on files that aren’t valid JS at runtime.
Note: I don’t see an explicit Nuxt 4 doc line that forbids type-only exports in runtime code; the guidance above follows from the module author docs on adding type declarations and the separation between build-time modules and runtime assets. If you need stricter direction, the docs don’t state it verbatim (Adding type declarations).
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
<@189706998231728128> Kapa.ai is still learning and improving, please let me know how I did by reacting below.
google helped me. I needed to run the prepare script again.
@danielroe but now i get the exact same error again 🙁
I managed to work around the error: https://github.com/nuxt/module-builder/issues/665#issuecomment-3271510499
GitHub
RollupError in Nuxt 4 module. · Issue #665 · nuxt/module-builder
Environment Operating System: Windows_NT Node Version: v24.7.0 Nuxt Version: 4.1.1 CLI Version: 3.28.0 Nitro Version: 2.12.5 Package Manager: npm@11.4.1 Builder: - User Config: modules, build Runti...