Nuxt•4mo ago

Adding Types To Nuxt Module

I feel like I am missing something here so sorry if this is a dumb question... I am building a nuxt module that is a collection of components to use across multiple apps. I want to add a few interfaces (currently all stored in src/runtime/types/[project-name].ts) to the module so they are available in all components. I'm not sure I am wrapping my head around the "Adding Type Declarations" section of the module author guide. Any tips? Should I be using addTypeTemplate or am I going down the wrong path?

11 Replies

larsmyrup•2mo ago

Hey Brick I'm having some similar challenges. Did you manage to solve this?

zoobzio•2mo ago

you probably want to be looking at addImportSources compsable to import specific types from a known file in the runtime dir: https://nuxt.com/docs/api/kit/autoimports#addimportssources if the types directory is full of types you want auto-imported, you can also use the addImportsDir composable: https://nuxt.com/docs/api/kit/autoimports#addimportsdir addTypeTemplate is used to define virtual modules that are created as part of the build process, if the type definitions already exist & you don't need to generate them you are better off using one of the first two

Nuxt

Auto-imports · Nuxt Kit

Nuxt Kit provides a set of utilities to help you work with auto-imports. These functions allow you to register your own utils, composables and Vue APIs.

Sybrn•2mo ago

How is it going for you? I'm currently building a module myself and managed to add types with the addImports util with the option type set to true. The types should be imported from a 3rd party package.

names.forEach(name =>
      addImports({ name, as: name, from: '@ark-ui/vue', type: true }),
    )

names.forEach(name =>
      addImports({ name, as: name, from: '@ark-ui/vue', type: true }),
    )

And my ts and IDE is happy, but Vue isn't. I get this error: Pre-transform error: [@vue/compiler-sfc] Unresolvable type reference or unsupported built-in utility type I don't understand where it comes from tho. I also tried to add a type template and use a nuxt hook to prepare the types. My repo (pr): https://github.com/carwack/ark-ui-nuxt/pull/1/files

GitHub

WIP: feat(types): add types for auto imports by carwack · Pull Requ...

WIP: Added 2 types for testing purposes only. Will change after I'm sure those two types work. The issue right now is that my IDE and TS plugin does find the types. But when running bun dev...

larsmyrup•2mo ago

Hi @zoobzio, Thanks for the answer! It's very appreciated. I've been trying using addImportsDir - and while it works for composables, utils etc. i can't get it to work for types. I have a types-folder and add it like: addImportsDir(resolver.resolve('runtime/types')) And everything seems to work in the playground. But if i publish the package with yalc (should be similar to npm, but makes testing locally a bit easier) and install it in another application i get this warning: WARN [unimport] failed to resolve "{path}/dist/runtime/types/field-with-validation", skip scanning Even though i can see the field-with-validation.d.ts field in the node_modules folder of the package. Do you have any ideas? Also when i run the playground in dev mode, types gets added to the .nuxt/imports.d.ts-file, but when i install the module in another project, that's not the case. Even though the utils, composables etc. all are in there. I'll try the addImportsSources, but it seems like it's more used for adding other dependencies types, than the ones i've defined myself in the module. Hey @Sybrn Thanks for contributing! Personally i can't see why that code wouldn't work.. hm. Seems like we're in the same boat.. Let me know if you manage to crack it - and i'll make sure to do the same! This code:

const types = [
        'ValidationMode',
        'FieldWithValidationProps',
      ]

      types.forEach((type) => {
        addImports({
          name: type,
          from: resolver.resolve('runtime/types'),
          type: true,
        })
      })

const types = [
        'ValidationMode',
        'FieldWithValidationProps',
      ]

      types.forEach((type) => {
        addImports({
          name: type,
          from: resolver.resolve('runtime/types'),
          type: true,
        })
      })

Made my types be globally available in the consuming application, so that's great. But i'm still very open to hear any ideas for making it happen more "automatically", importing the entire directory or similar.

brickOP•2mo ago

Hello! Sorry for the delayed reply - I was away from my computer for a bit. I couldn't remember what I ended up doing but just looked back at my code and I put all of the interfaces in each component. Ended up working pretty well for my needs but not necessarily a fix to the issue. Hope you get it figured out!

zoobzio•2mo ago

@Sybrn it kind of sounds like you are developing UI libraries as standalone Nuxt modules & are expecting the components you define in your module to behave in the same capacity as they would if you were defining them within a Nuxt application (i.e. auto-imports of types/utils within components defined in your module) this unfortunately will not work, auto-imports are made available to the Nuxt application as part of the build process which your modules are not subject to until they are used within the consuming application. this is why your imports are available in the app but not your module components for the most part this is intentional, components within modules should not rely on auto-imports to avoid type collisions & other nefarious gotcha's, I would recommend using explicit relative imports within a runtime directory not only as a solution to this problem but also as a general practice when developing any module consumed by a Nuxt app that isn't really a fun answer though, so you can get what you are looking for if you are willing to refactor your module into a nuxt layer, check it out: https://nuxt.com/docs/guide/going-further/layers

Nuxt

Authoring Nuxt Layers · Nuxt Advanced

Nuxt provides a powerful system that allows you to extend the default files, configs, and much more.

zoobzio•2mo ago

layers work like normal nuxt apps do, define your utils/components in the normal directories & auto imports work fantastic in your consuming app, you just extend the layer & you have access to all the exports that layer exposes w/o needing to explicitly import them using the @nuxt/kit functions

zoobzio•2mo ago

@larsmyrup inferring from the error message, it kinda looks like you are building your runtime dir into a dist dir when that may not be necessary anything in a runtime dir should be built as part of the consuming application & not before it is consumed, I generally opt to separate the runtime dir from my src module & add runtime to the package exports w/o any kind of build defined within runtime should be .ts files rather than .d.ts, Nuxt will build your runtime for you before performing the imports & you might see a change (technically you are building the same file twice rn, could be related to the problem) I can't say much more than that w/o actually troubleshooting, thats just a gut reaction from the information available to get a better look at the module structure I know works, you can take a look at this module which demonstrates the concept: https://github.com/zoobzio/ltrl/tree/main/packages/nuxt-ltrl it's not at all related to your module most likely, but it's a good demonstration of how to separate the module src that you need to build & the runtime code you want to be built by Nuxt

GitHub

ltrl/packages/nuxt-ltrl at main · zoobzio/ltrl

🍱 Compose literally-typed constants, tuples, enums, & more from standard JSON. - zoobzio/ltrl

Sybrn•2mo ago

This is great information! 🙏 Thanks for pointing it out, I had no idea that there was such a difference. It's indeed true that the components and types UI library are/should be available when they are consumed only. I'm going to read up on the explicit relative imports within a runtime directory. And look into the layers. Thanks for pointing me in that direction 😊

larsmyrup•2mo ago

@zoobzio Thanks for getting back! We're using the nuxt-module-builder and trying to follow the pattern established by component libraries like Nuxt UI. Which seems to do the same. However i agree that having d.ts-files in the runtime folder seems off and like i'm missing something 😅

zoobzio•2mo ago

happy to help!

Gaming

Programming

Adding Types To Nuxt Module