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
Hey Brick
I'm having some similar challenges. Did you manage to solve this?
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 twoNuxt
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.
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.
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/filesGitHub
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...
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:
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.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!
@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/layersNuxt
Authoring Nuxt Layers Β· Nuxt Advanced
Nuxt provides a powerful system that allows you to extend the default files, configs, and much more.
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@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 NuxtGitHub
ltrl/packages/nuxt-ltrl at main Β· zoobzio/ltrl
π± Compose literally-typed constants, tuples, enums, & more from standard JSON. - zoobzio/ltrl
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 π
@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 π
happy to help!