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
8 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.