Adding Types To Nuxt Module

[grave wolf]

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?

[spark flame]

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

[paper saddle]

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

[forest beacon]

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 }),
    )

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

[spark flame]

Hi @paper saddle,

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 @forest beacon

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!

[spark flame]

This code:

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.

[grave wolf]

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!

[paper saddle]

@forest beacon 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

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

@spark flame 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

[forest beacon]

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 😊

[spark flame]

@paper saddle 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 😅