DejaVue

Are you using Nuxt and want to hear some insights you weren't aware of? Perfect! Then this DejaVue podcast episode is what you need. Michael and Alex are going through more than five big tips around Nuxt, from features under the radar over to a big chunk of amazing benefits and why they exist, all from Michael's Nuxt Tips Collection* which releases on Aug 5th (and of course we got a discount code for you)!
 
In addition, further topics around the vue-based meta framework like the difference between @nuxt and @nuxtjs modules are discussed as well.

Enjoy the episode! 

Chapters

  • (00:00) - Welcome To DejaVue
  • (01:49) - Tip 1 - Disable Nuxt's auto imports
  • (03:54) - Opinion on Auto Imports
  • (08:12) - Tip 2 - The .nuxtignore file
  • (10:06) - Tip 3 - Dedupe data fetching
  • (12:04) - Tip 4 - Custom keyed composables
  • (17:00) - Tip 5 - Utilizing Layers
  • (21:41) - App Config
  • (25:50) - Why is app.config.ts an extra file?
  • (28:34) - The different types of Nuxt modules
  • (36:24) - Why are core modules not part of the core?
  • (38:41) - Go and write a module!
  • (40:54) - Upcoming Vue.js conference
  • (41:34) - More Tips?
  • (42:55) - Wrapping Up

Links and Resources



Links marked with * are affiliate links. We get a small commission when you register for the service through our link. This helps us to keep the podcast running. We only include affiliate links for services mentioned in the episode or that we use ourselves.

Creators & Guests

Host
Alexander Lichter
Web Engineering Consultant • Founder • Nuxt team • Speaker
Host
Michael Thiessen
Full-time Vue educator
Editor
Niki Brandner
Sound Engineer

What is DejaVue?

Welcome to DejaVue, the Vue podcast you didn't know you needed until now! Join Michael Thiessen and Alexander Lichter on a thrilling journey through the world of Vue and Nuxt.

Get ready for weekly episodes packed with insights, updates, and deep dives into everything Vue-related. From component libraries to best practices, and beyond, they've got you covered.

Alexander Lichter:

Hey, everybody. Welcome to DejaVue.

Michael Thiessen:

Your favorite Vue podcast. You just don't know it yet. I am Michael Thiessen, a full time Vue educator and instructor, and I'm here with Alex.

Alexander Lichter:

Hey, everyone. Yes. Alexander Lichter here, web engineering consultant and Nuxt.js team member as well as YouTube and Twitch content creator all around Vue and Nuxt. They also love JavaScript and TypeScript and stuff. And today, we bring you some awesome Nuxt tips straight away for you in a digestible way that you might not know already because there is so much around the framework.

Alexander Lichter:

Like, it's it's tough to have the overview about everything. Even if you read the docs nowadays, maybe in a week or 2, there are some new features added. So, yeah, we have some hidden gems, so to say.

Michael Thiessen:

Yeah. I have been, for the last month or 2 now, been working on a book called Nuxt Tips Collection. Taking my knowledge of Nuxt and also scouring the docs, diving into the source code a little bit and trying to find like those interesting things that are useful and maybe a little obscure. Maybe you didn't know that they were there. And I packaged it into an ebook and it will be launching on August 5th.

Michael Thiessen:

So if you're listening to this podcast right when it comes out, that's next Monday. But you can get a $10 off this book with the DEJAVUE code. So that's more than 10% if you are, you know, listening to this and you want to grab that book. You know, we'll, leave that teaser there. Let's get on to some tips.

Alexander Lichter:

Yeah. Let's do a little sneak peek because all these tips, as Michael said, will be part of Michael's books. You'll get some free content here straight away for you. What a steal,

Michael Thiessen:

So this first tip is one that I think many of you will enjoy. It's all about being able to disable the auto imports in your Nuxt app. So a lot of people love this feature. You don't have to import things. It just magically works.

Michael Thiessen:

But many of you find it frustrating. And now we can disable these with the imports dot scan configuration. And you set that to false and it will stop Nuxt from importing your composables and your utils.

Alexander Lichter:

Exactly. And I mean, before we had, like, an auto imports false flag already under the imports, key in your Nuxt config, but it only stopped from, like, actually importing packages and, like, imports from, like, Vue, for example, but not your own local folders. So luckily that got improved and well, maybe for the people who really don't like that, yeah, you can disable this. It's not a problem because that's the whole idea of Nuxt. No vendor lock in.

Alexander Lichter:

If you don't like these auto imports, if they're too magical for you, then feel free to disable them. And, there's also a very nice plugin, for ESLint. It's actually a Nuxt module that will hook into the Nuxt ESLint module from Anthony Foo also linked all the way down in the show notes, which, actually will explicitly add these imports instead of using auto imports to your code base. So check that out, and, if, something doesn't work, give feedback on repository, but it's pretty smooth.

Michael Thiessen:

Yeah. And it's important to to note that this will not disable the auto imports for your components directory because that lives in a different config option. There's the components property that you can configure where you can specify how different directories are gonna load components, whether you wanna load them all as global components or have them auto imported, all that kind of stuff. So if you want to also disable auto imports for your components, you gotta go to that configuration property instead.

Alexander Lichter:

Exactly. And maybe while we're talking about auto imports, I wonder what's your take on them. Like, I I also have some opinions, but I'm really curious, Michael, what do you think about auto imports? Do you think they're too magical? Do you like them?

Alexander Lichter:

Would you, like, leave them on? Or as soon as that option came out, like, yep, false, disable?

Michael Thiessen:

So I actually really like them for the most part. And, I think they're great for for smaller projects for sure because you don't want to deal with all this boiler plate and overhead, and you can just get started. And there's not a lot of downsides in doing that. But I think as the project grows, then there's more likelihood that you're going to have, you know, several different overlay dropdown sidebar components or, you know, whatever. That's not a real component.

Michael Thiessen:

But like you're gonna have, oh, this component is gonna be used in this part of the app. This component is gonna be used in this part of the app and you are more likely to run into naming collisions that way. And it can be tricky because, you know, sometimes you the the clearest name for something is just like header component that you wanna use in a place, but then you've got 7 different header components.

Michael Thiessen:

And which one will show up when you do the auto imports, it's unclear. And so I think in some ways, having the manual imports makes it, a lot more explicit and, yeah, solve that problem.

Alexander Lichter:

Interesting. Yeah. Like, so I'm I'm a big proponent of auto imports mainly because I think if you see, like, a ref or computed in your code, then if if you use Vue for a bit longer than a couple of hours, you probably know it's from Vue. And then, of course, with the obscurities, like, I sometimes agree.

Alexander Lichter:

If I go into, like, a new project, and then it's like, okay. Is this a composable from Vueuse or another library or another library? Also about Vueuse. We also did a podcast episode on that, so definitely check that out. Link also in the show notes.

Alexander Lichter:

Then it it might be a bit tricky, like, to find the origin, then usually people search for it or they click on it, then they land. And that's a bit of a pity, like, the TypeScript file for that because the components, like and also the, the composables and utils that all, like, have basically global TS files that are in your .nuxt folder because that's how you make sure TypeScript still works. Luckily, there's also Versus Code extension that will then straightaway bring you to the source file, which is what you usually want, and then you're there. But, yeah, sometimes it's it it can be a bit of score. With the component naming, though, I think this is mainly solved by, something called path prefix.

Alexander Lichter:

So if you have, like, multiple headers, then I mean, maybe you would start even a bit earlier. If you say you have an app pattern, you have several variants, then you probably should name them if you can't really, like, set them apart by props. And then you can also go with, like, okay. Maybe there's an app header or a user's header or, I don't know, a sidebar header or whatnot. And then you can say, let's create folders in the components folder.

Alexander Lichter:

And then you say, I have components/app/header, and then you auto import app header instead of just header. So in that way, it can be a bit more clear and also correspond very well with your project structure.

Michael Thiessen:

Yeah. If you're more disciplined with naming, yeah, then then that's not really an issue with the naming collision thing. So I'd agree with you there. I think for myself, I'm just maybe a little too lazy with with naming and and that's my my own problem.

Alexander Lichter:

Naming things is quite hard. Like, it's it's difficult. Don't get me wrong. Like, I always I'm on stream. Be like, hey.

Alexander Lichter:

What I what I named it? Like, I had a stream and named things like a to do module because, like, just modules, it's so broad, but I didn't have a good term. So I just first go with to do and it's still in the code because, well, still didn't find a good a good name for it. So I I totally understand that. And in a way, I also value explicitness in code.

Alexander Lichter:

It's just as long as I can find the source pretty quickly, which I can by clicking on it with that little Versus Code extension, I personally am good. But luckily, that's the beauty of it. You can choose for your own project, for your company's projects, what to do. Hey. As you said, Michael, lots of people, they were really, really looking forward to a feature to disable these things.

Alexander Lichter:

Also in Nitro as well, not only in the Nuxt side. And, yeah, that's that happened.

Michael Thiessen:

Alright. Next tip is a file that you maybe didn't know Nuxt could use, and that's the .nuxtignore file. So this works exactly like a dotgit ignorefile, except it will cause Nuxt to ignore some files when it's, building your app. So if you have some Vue files in there or other things that you don't actually want Nuxt to import for whatever reason, or not import, but use in the build, then you can put your glob pattern in there for the files or the directories or whatever it is that you want and configure it that way.

Alexander Lichter:

Yeah. I think also something that's pretty underused, mainly usually, when I try to ignore certain files, I just put a dash in front because that's the ignore prefix that set a Nuxt. And you can also configure it if you want to, like almost anything else. So if you have, like, a script that shouldn't go all the way bundled in your application, but maybe it's in a utils folder, then, yeah, putting a dash in front will just ignore it for Nuxt, and and you're good. But I also think if the prefix is not enough or if you need certain names to be, accurate or want, like, a good overview of what is ignored in general, not just, like, have a dash here, a dash there, then the Nuxt ignore is also a good option.

Michael Thiessen:

Yeah. And a lot of the things in Nuxt and the way that they're loaded in can be configured based on directory and names. So like the components that we mentioned in the previous tip, you can configure those how you want. And so, in a lot of ways we don't even need this dotknockstein ignore file, but it is there if you need it.

Alexander Lichter:

Exactly. And especially if you are familiar with the git ignore, docker ignore, all these ignore files, then it's pretty easy to, like, just say, okay, I can do literally the same thing just for Nuxt and I'm good. So, yeah, why not?

Michael Thiessen:

So tip number 3 is on deduping fetches. And so in Nuxt, we've got a bunch of different data fetching composables. We've got use fetch, we've got use async data, and then there's like some lazy versions of that as well. And we can actually dedupe fetch requests now. We can so with use fetch, with use async data, if the arguments that you pass in are reactive and they update, then a new fetch will happen.

Michael Thiessen:

And that's one of the the beauties of these composables is that they are reactive. However, if they are sending lots of requests, how do you handle that? If you've got a request already outgoing and you're waiting for it, do you create a new request or do you wait for that existing one to come back and resolve? So that's what this dedupe parameter lets us do. If we set it to defer, then we will defer to the original request and wait for that to come back and we won't send a new one.

Michael Thiessen:

But we can also set it to cancel, so we can cancel that original request in favor of this new one and get the more recent latest data instead.

Alexander Lichter:

Exactly. I think it's also something people should utilize more, like deduping requests, especially if you send lots of requests. It might be really good to just not them let them run forever forever or like, hey. This is new because okay. Let's let's stop it.

Alexander Lichter:

And it's a nice way to finally, like, granularly set up the behavior that you want, and you pass that basically to the options in use fetch or use async data. So for use fetch, that's the second argument where you have all your options in. We can pass a custom fetch instance, headers into, and so on and so on. You know? For use async data, it is the 3rd argument because you should set a key first.

Alexander Lichter:

We'll come to that in a bit too. Then your, like, async fetching function or whatever you wanna do there, ideally for outside effects, then we have some options.

Michael Thiessen:

Alright. So this next tip is about custom keyed composables. So we, we know that there are some composables in Nuxt that will have this auto generated key that's put in. So useAsyncData, as Alex just mentioned, gets this key, but useState also has this key and a bunch of other composables that Nuxt comes with. And this key is there so that we can make sure that these calls are going to be unique.

Michael Thiessen:

So for example with useState, we want to make sure that we only have that one version, that we're referencing the right version of the state, so we can basically like naming the state that we are actually using. But if you don't provide that key yourself, then Nuxt will actually figure out its own key based on where in your code you're using that that method. So if you've got it on one line, it'll use one key. But if you have it a few lines down, it'll use a different key. So that means make sure that it's going to be a consistent key every time you you use it.

Michael Thiessen:

And this is important because then when we go from the server side and then hydrate back onto the client side, then that will maintain, like we'll be able to sync the data across from from client to server.

Alexander Lichter:

Correct. And commonly, like, in almost all cases, you want to provide an own key. The only exception commonly is useFetch because in useFetch, the key is just generated by the URL pass and the params and you're good mostly. You can also set a custom key there if you want to, but for use async data, for example, so you state, I probably wouldn't rely on the Nuxt generated key because it does it with best effort. But let's say, like, it's all global state.

Alexander Lichter:

Right? So let's say you use use state in a component, but you want, let's say an image there, but you want to do it per component, then if you just give a static key or no key at all, it will be the same key for each of the components because it's only depending on the line and the files. We like an my component.vue line 15. No matter which instance it is, it will always be the same key and magically, you share state across components that you probably don't want. So the best solution there is, well, pass in a key, for example, through a property or, well, if you actually want a global state, then that might be okay.

Alexander Lichter:

I still would probably extract into a composable to make sure, hey. This is intended in a way. And or, like, yeah, use a static key that is is definitely, like, unique and you only use the component once, that's also fine. If it's just like a tiny abstract around it, but the generated key can be nice for the start, especially if you said, like, okay. I use it in app of view.

Alexander Lichter:

It's probably fine, but in everything that you use more than once, I would really recommend setting that key on your own.

Michael Thiessen:

Yeah. I agree. It's better to be explicit with these things. But the the interesting thing with this is that you can get Nuxt to auto inject that key into your own composables if you wish. And so it will look at the number of arguments that you've passed in when you're using it.

Michael Thiessen:

And it will, if you've used less than it knows that you haven't provided that key yourself. And so it'll know, okay, I've got to inject that key for you. And so there's a list of these composables in the Nuxt config and you can add your own composables to that list and then, you know, get that key in the same way. But again, it's probably better to just make that explicit and, pass in your own key instead.

Alexander Lichter:

I've never seen that functionality, like, used in a real word application. Like, I I haven't seen all the Nuxt apps, obviously. But if one of you out there uses that functionality, I would be super curious to hear what you're doing with it and why. Like, it will be very interesting. And also for the key generation, as as Michael mentioned, like, it will be auto generated by the line and how often the the method is basically in that file, like that useState, useFetch, useWhatever.

Alexander Lichter:

And it's it's done through an unplugin. So, yep, that's, that's pretty cool. And, yeah, it's it's pretty smooth to see how how it's happening under the hood. But, yeah, once again, can never say it often enough, set it on custom key.

Michael Thiessen:

I imagine this is probably more useful if you're authoring a library or or something else like that, and you want to make the default out of the box experience a little bit better and not require as many parameters to be passed into your method, you can say, well, you don't have to pass this in, but you should. And then, like you were saying before, just pass in that key for the most part.

Alexander Lichter:

And then we we come to one more tip, which is probably a a bunch, like, a a big group of things, and it's about layers. Michael, tell us more.

Michael Thiessen:

So there are a lot of interesting things with layers and Alex, you've recorded a great video on these and I highly encourage everyone to check that out. Also, Dave Stewart has this massive in-depth article on that and gives you some ideas and tips on how to, like, migrate from non layers to layers in different ways. And one of the the more interesting things about layers for me is that you can actually have different configs per layer. So if you want your components to be imported differently in different layers, you could do that. If you want to take a giant runtime config with, you know, dozens and dozens of different variables that you're defining, well, you can split that up into just the things that that layer needs.

Michael Thiessen:

And Nuxt will do this big deep merge on it. And then, you know, at the end of the day, it works the same. But when you're trying to find, okay, where is this thing defined? Well, the URL for your blog or some other settings for the blog, well, they're defined in the blog layer. And so you can just go straight there and you know where to find it.

Alexander Lichter:

Yeah. And I mean, same for for like components, pages, and so on. So you have a really good opportunity to slice your application by scope, by feature, however you wanna call it, like, to have even some domain driven design going on just by using layers. And then you never worry, like, okay. I have components for the with thousands of components.

Alexander Lichter:

Where do I find things and how do they belong to together in a way? Like, how they're coupled? With layers, you basically have a very nice, encapsulation by that feature, and you can even define, like, a base layer if you want to that all of them use eventually, if that's if that's needed. And with Next 4, you even have a layers folder straight away, at your fingertips in your own application directly, like, like it works with modules nowadays. You wanna define local modules.

Alexander Lichter:

Same way works with layers. We have a slash layers, also shown it in the, next for folder structures video, and then you can just put in all the layers that you want there, which is great for slicing per feature. But if you have like more complex layer setups, like layers needing layers needing layers, that's might not be the best approach. Still it's very useful for a vast majority of case.

Michael Thiessen:

One thing I didn't mention about Nuxt Tips collection earlier is that I'm also including different code demos. So, like, with commented code that you can go in and interact with the different things and play around with the code to see how things work. And one of the demos is on layers. And that in there, you can see different things about how the for example, like importing components and other things between different layers and how the naming collisions might resolve themselves. There's some interesting things there that, that are good to keep in mind.

Michael Thiessen:

But, but what's also interesting is that you can import child pages between layers. So if your root or like your main app has a page with a Nuxt page on there, Nuxt page component that will render out child pages while each of your layers can contribute child pages, as long as they're, you know, named the same way that you would normally name them, doesn't matter if they're in a different layer or not. And so there's a demo in there about how that works and it's yeah, it's pretty, it's pretty neat to see how it kind of just like, you know, it just works nicely. It's not too hard to think about in a in a lot of ways. And I think the layers implementation is pretty nice way of splitting things up.

Alexander Lichter:

I still think there can be some improvements to layers even more, but there are some technical hurdles like TypeScript support, for example, is a big one. But on all, like, it's really worth giving it a try. There are some caveats to check, like, not using the the at and tilde anymore because they only refer to the right path at runtime and not to the path in the layer, and a few more things. But, I mean, other than that, it's, it's pretty smooth. And when you use the layers folder, that might not even be a problem, but I would I would double check on that.

Michael Thiessen:

Yeah. We'll have we'll have more on, Nuxt 4 in the future. So yeah. Stick around for that in future episode. I'm sure there will be one when it comes.

Alexander Lichter:

One day when Nuxt 4 will be released. And while we are at layers, maybe there's also a good idea to talk about something that's very often, used in, like, together with layers, but that people might not know about straight away, which is, something called app config.

Michael Thiessen:

Yeah. So there are 2 ways to configure your app. One is runtime config. The other is app config. And they are different, which is why they have different names.

Michael Thiessen:

But it is confusing to know the differences between the 2. And I often find myself referring back to the docs. And I even wrote an article for Mastering Nuxt on the differences, and I keep referring back to that article because it's one of those funny things where, you know, even if you write something about it, you know, a year later, you're, like, googling, and then you end up on your own article trying to remember, oh, right. I guess I did know this at one point.

Alexander Lichter:

Can't remember all the things huh.

Michael Thiessen:

Yeah. And so there's there's big differences between like build versus run time. One of the things with AppConfig is that you can use hot module replacement with it. So as you're developing, you can update things. You can actually have good TypeScript support, which is why it's in like it's separate file.

Michael Thiessen:

Runtime config is more for adding an environment variables and things that are gonna be, configured at runtime. So if you have different authentication URLs for different environments, like your staging and your production, Well, often you build the app once you run it in staging and then once you've tested it, everything's good. You just kind of like move it over to production. Well, you need to be able to update those environment variables for production now. And so with the app config, those things are already built in at at build time and they're stored away.

Michael Thiessen:

So you can't change them from the environment, basically. So those are those are some of the differences.

Alexander Lichter:

Yeah. I think, like, what you mentioned for runtime config is very important. Also, like, if you don't rebuild your application but just wanna change things, like, I don't know, deploy to 4 different Docker containers, and these 2 should have a different load balancer or that should be a different API, and you don't want to rebuild it for each of them, then it's it's very essential to to actually use run time config for the end variables, which is one of the most common mistakes people do. With app config, it's also important to mention these are all determined at build time. Like, you basically set the values.

Alexander Lichter:

You they're, like, not, like, inferred for env variables or similar, but runtime config, for example, has to be serializable. Like, you can't use functions, you can't use classes, whatnot. On app config, you can use more things than just JavaScript primitives. So you can use all these things because it's JavaScript. The file will be bundled, so don't put any secrets in there, and it can be used.

Alexander Lichter:

And with layers together, it's pretty nice because also for the app config, you have some kind of merging strategy. You can even define custom mergers for the property you set up. So let's say you have an array and say, okay. The other array should replace that one or merge or, like, dedupe, and and put together whatnot. You basically sky's the limit.

Alexander Lichter:

And this is also once again, made possible by various unjs packages, under the hood. So the the idea there is it might be a bit confusing that, like, app config and runtime config and the Nuxt config, they're, like, all exist in a way, but each of them has their purpose. Because also once again in the Nuxt config, everything is has to be serializable. So you can't set up, as I said, like, classes, functions, not nothing else besides that. So that's what app config is there for, but it's important to know that this will all add to your bundle eventually

Michael Thiessen:

Mhmm.

Alexander Lichter:

And it will also be loaded, with with Nuxt together. So there's no, like, way to defer that. It's in, like, oh, yeah. Configured. I don't I don't need it right now.

Alexander Lichter:

Good part is also both are reactive, and so you can do whatever you want with them and configure things.

Michael Thiessen:

Yeah. And I should note just to, throw this in there that the app config is not a place to put secrets because it is bundled and the runtime config can have your secrets on there. So that's another thing to keep in mind. I think what confuses me about them is that they're so the, the one has a file app dot config has its own separate file whereas runtime config doesn't have a separate file and it's like part of the Nuxt config file. And it seems like not, not consistent in that way.

Michael Thiessen:

And I don't know if it really makes that much of a difference, but it's, it's one thing that sort of, trips me up sometimes.

Alexander Lichter:

Yeah. The the the point is file is an extra file because that's the the easiest way to actually bundle then just to, like, okay, take the whole file, put it in the bundle, you're good. While, like, in next 2, the runtime config was a weird mix of both worlds. Like, some parts could be somehow taken over, but not really. And, like, we want a clear separation between that's the build time config.

Alexander Lichter:

Like, it's happens before Nuxt is, like, being spawned. You need all this information to actually get Nuxt up and running. It's also why you, for example, can't use aliases like the tilde or add in your Nuxt config. And then you have that that app config, which is basically just a big, export, default with all the values that you want in there that will be just used to for your actual running application. And then you can set things like, for example, for theming, for settings, layers can toggle certain settings for Eula.

Alexander Lichter:

So one one case I know for a client of mine is that, okay, we have all these tiny layers modules, and the idea is that eventually customer a wants, like, these 3 out of the 5 modules. Customer b wants all and customer c only like 2 of them, but different ones than customer a. So you could say, okay. I built that application. I just use these layers, plug them together.

Alexander Lichter:

They just work out of the box. It's fine. And in your application, you know already which layers are enabled because each layer just contributes something to the app config saying, hey, I'm on here in my settings and I'm on and the rest might not be.

Michael Thiessen:

Yeah. That's an interesting use case for that is making your app aware of the different layers that exist.

Alexander Lichter:

Yep. And you can also use it for feature flags even if you want to just say like, okay, We toggle certain feature flags. I mean, it's a it's a big thing, nowadays. Just like, okay. That should go on.

Alexander Lichter:

That should go off. You could probably also do it for a runtime config. Like, that would work in a similar way. If you need to have it at runtime feature flag wise, then that might be a better solution. But if you need them at build time, that config might be a way to go there.

Michael Thiessen:

So this last tip is less technical, and it's about the different modules that we've got in Nuxt or in the Nuxt community, I should say. So there's sort of 3 main categories of modules. There are the official modules by the Nuxt team maintained by the Nuxt team. So for example, Nuxt Image, next content. These ones are maintained by the team and, you know, as a part of the ecosystem here.

Michael Thiessen:

Then the next is community modules. And these are not they're they're sort of like curated. How to, they're not they're not really approved or there's not really, like, a vetting process. I'm not sure what the process is. Maybe Alex can speak more on this.

Michael Thiessen:

But there's sort of some some way of saying, okay, these are useful for the community. Let's move them into a list that's easily searchable. I think this list is also part of, nuxi when you do like the add modules. It's it uses that to to look up. And then there's these 3rd party modules where if you want to create a module, you can just create your own module, prefix it with Nuxt Dash, push it to NPM or wherever you want to push it, and anyone can download it and away you go.

Michael Thiessen:

The interesting thing here is the difference between the official modules and these community ones is the official ones are prefixed with the @nuxt, the community ones are @nuxtjs. So it's a small difference and maybe a little confusing. But when you're looking at these packages, that maybe gives a little bit more information on where these packages have come from and how they're being maintained.

Alexander Lichter:

Yeah. So so a few things to add there. Like, the official modules, I think, is also important to know, like, besides the good, like, first party support and, like, quality wise, pretty much up because we we maintain them, then, like, they also might be auto installed. Like, for example, Nuxt Image might be auto installed if you use Nuxt content or, like, if you use Nuxt Image the first time and don't have it installed, it just ask you, hey. Using your Nuxt Image component, wanna install, the Nuxt Image module.

Alexander Lichter:

And Nuxt fonts right now, not all installed might be in the future. So just to improve things. Also other modules like Nuxt scripts, for example, which is in public preview right now, they they all, like, as an idea can be an integral part of most applications. Like, if you use web fonts, then, like, Nuxt fonts is the way to go for you. If you use scripts, like, third party scripts tracking and so on, then Nuxt scripts should be something you take a look at.

Alexander Lichter:

If you use images, Nuxt images. So it kinda makes sense. But if you say, like, yeah, you know what? I have a content heavy side, not many images or then you don't need it. Like or if you said, like, I don't need web fonts, then that's good.

Alexander Lichter:

I, for example, rarely use web fonts. But if I do, I use nice fonts there, and that's an important part. The community modules, that's that's always a tricky one. Like, we have the big list on on nuxt.com. Right?

Alexander Lichter:

Nuxt.com/modules. And on there are basically all the official modules, so at Nuxt, and the community modules, so at Nuxt. Js. And you can list a module by basically sending PRs and, hey. Okay.

Alexander Lichter:

This is my module. How does it look like? So we can put it up basically up there. And in the community modules, you basically have things like Tailwind CSS. So they're okay.

Alexander Lichter:

The Nuxt team, like, we don't plan making Tailwind a a core part of the framework, Or like, we still have a first party integration for that. Right? And it works pretty well. So you don't need to do much install the pain in a tailwind module and you're done. Same with Pena, for example.

Alexander Lichter:

So the the background of that is that in the end, people, like, might maintain their own modules. They can put it into the Nuxt modules organization. They get, like, a nice, like, nice banner image, and they can also put it, of course, on the site. While it's also fine if it's like, okay. I want to maintain it on my own.

Alexander Lichter:

I don't have to put it to the Nuxt modules repository. That's all good. You can probably you can still submit it. That's, like, fine. So don't don't worry too much about it.

Alexander Lichter:

There are also, submissions that don't have the Nuxt modules tech, but still so there's there's a bit of way to go there. The other thing which might be considered like, the naming wasn't always that clear. We did a little bit of cleanup, throughout some time because I admit the prefixes were confusing. Also back in time with Nuxt 2, we had, like, @nuxtjs/axios even though it was used everywhere, it was like @nuxtjs. And I remember Eduardo making that meme where you have, like, the 2 buttons and the guy doesn't know which button to push and was like at Nuxt and at Nuxt.

Alexander Lichter:

Js. Like, yeah, which prefix is the module? Could also be a a fun game, actually. So if someone wants to build it and check NPM for that, it could be a fun project with Nuxt. Just saying.

Alexander Lichter:

So, yeah, Nuxt Nuxt modules in in that way, it's really nice. I'm really happy about all the contributors, like, in the list. I have to check how many, but, like, we have so many, like, modules in that list that, for example, yeah, Tailwind, i18n, VueUse, Pinia, the dev tools, of course, there's another official one, by the way, that we, we we didn't even mention, but quite some of them, for for various libraries that make integration easier. And also for the community modules, lots of them are still maintained by parts of of the team, like Daniel maintained quite some modules, I to, Julian, Lucy, and so on so on. So harden as well with all the Nuxt SEO things, right.

Alexander Lichter:

So just Khonjan, just because it's a community module, it's not, like, worthless or, like, bad. I think I would always prefer an at Nuxt JS module over a 3rd party one just because, okay, it's under Nuxt modules org. People have a look in it. There's also the ecosystem CI to mention. So we have the CI in Nuxt to make sure we don't break any modules, and we check also lots of Nuxt modules 1 at once.

Alexander Lichter:

So we make sure things work nice and otherwise we send a PR, or like, hey. That broke. Let's fix it together. So that's a good one. But I understand sometimes the confusion.

Alexander Lichter:

I would probably just take a look at the list. Also, the dev tools, they use the same list. And with nuxi add, they just query the API that's behind that. Because as I said, every time you submit a PR to add a module, it will be just a big list and you can query that. It's like, okay, let's install that module and do do things.

Michael Thiessen:

Yeah. I think it's great to get that extra background and information on on how the modules system works. And, yeah, it's a good point you bring up about that it's not that these official ones are like somehow better. It's just that they make more sense to be part of Nuxt as and not just part of the community. And that means that they are more light like, they're more actively maintained.

Michael Thiessen:

But, like, as you mentioned, there are some community ones that are actively maintained by people on the Nuxt team. So it's not and and just, you know, even if someone not on the Nuxt team maintains a module, that doesn't mean that that module is bad in any way. And it's not like the community modules are, yeah, better or more trusted. I think that's also a good thing to to point out. Like, there are a lot of modules in there and your team is not, you know, reading through each line and making sure there's like it's written well or anything like that.

Michael Thiessen:

That's an impossible task, but it's there. It's searchable, and you can see what's going on. I'm sure if there were any issues raised with a module and, like, weird shenanigans going on, it would not be listed on there anymore. But it's always, a tricky thing to figure out which versions of of things do you, do you install?

Alexander Lichter:

Yeah. That's true. That's true. And also to add, I think the core modules are basically I think they are for more use cases. They're not bound to a library.

Alexander Lichter:

They're not bound to a certain web fonts. You can use them any kind of application images, same with your dev tools. You might use it for for anything, scripts and so on. So they're more general purpose while most other modules like Pinia, of course, it's the preferred state management tool in Vue.js.

Alexander Lichter:

But on the other hand, it's also like if you want to use useState instead, which you totally can, or some own composables is fine. So it's a choice you make while I think the at Nuxt modules are more like these are best practices for everything around the ecosystem, so you should use them when you use a web phone or an image, to make things, well, more performant, more accessible, and so on and so on.

Michael Thiessen:

Yeah. It's almost like there's they're, like, extensions of Nuxt itself, which is an interesting question of why why have a module for something that's installable instead of having it just be part of Nuxt?

Alexander Lichter:

That's a good one. That's good that you that's really good that you bring it up because it's it's a fair question. And I think the main point is the versioning part because, like, Nuxt can run without it. Like, fine. You can use image an image tag without using Nuxt Image.

Alexander Lichter:

But Nuxt Image gives you lots of benefits in terms of performance, image providers out of the box, and so on and so on. But if there's a bug fix in Nuxt Image, you don't have to wait for Nuxt release. If there's a new feature in Nuxt Image, you also don't have to wait for Nuxt Release that's independent, same for fonts, scripts, ESLint, and so on. Plus, if we'd have to merge onto core, it would I think it would slow down lots of processes. So Right.

Alexander Lichter:

The the idea there is to have a bit of independence in terms of bug fixes, features, versionings, and basically end up with more productive and better results there while still giving people the choice to let's say, if you don't use a web phone ever, then you don't need the modules, so you're good. And you don't have a lightweight core. Right? You don't need the code in the end.

Michael Thiessen:

Yeah. Yeah. Okay. I like that. Makes sense to me.

Alexander Lichter:

Convinced. Perfect.

Michael Thiessen:

Convinced. Didn't take much convincing.

Alexander Lichter:

Yeah. Fair. Fair. And also, like, on that point, to anyone listening, if you ever wondered, like, oh, yeah, I have a cool use case for a module that you wrote yourself because there is none or a good alternative. There's a module author's guide also linked in the description.

Alexander Lichter:

Of course, also it's in the docs. So if you're interested, publish it, like, why not mark it as, hey, it's work in progress, and then share it with us if you want some feedback, like, share it on the Discord, for example, of Nuxt or, yeah, get some eyes on it if you're interested in that. Because if this code there and written any way that step to generalizing is often, at least, not always, but often not too tricky. Sometimes it is, but that's that's, yeah, depends a bit on the library. So, yeah, give it a go.

Alexander Lichter:

If you have a module anyway, then, why not publishing it?

Michael Thiessen:

Yeah. Publish it. And the first step is usually to get it to work for one use case and then another use case, and then, yeah, getting more eyes on it, Especially like eyes of other people who might be more familiar with having built modules in the past or whatever. Like that's probably better than you just, like, trying to perfect it in in your own secret, repost hidden away somewhere.

Alexander Lichter:

100%. And also it's to capture people. Yeah. That's true. That's true.

Michael Thiessen:

It's hard to, like, push and, like, show off things that are that don't feel like they're polished and don't feel like they're good. But, Yeah. It's often the fastest way.

Alexander Lichter:

On the other hand, like, we for example, we we live stream, like, somewhat regularly, at least for me. Like, more some of the stores that there's less. And then we also show off things that aren't polished because we're building them right now. And, of course, not everybody is doing live streaming or live coding or content or whatever, but same idea here. Like, it's it's totally fine.

Alexander Lichter:

Nothing is perfect on the first run and shouldn't be. I mean, that's why your market like, hey. It's work in progress. 0 point something. People can still have a look, can do some suggestions, and so on.

Alexander Lichter:

So don't be afraid. Go for it, and nobody will judge you. It's probably opposite of people. Be like, hey. Cool.

Alexander Lichter:

Did you open source it? So Yeah. There's no reason not to do it.

Alexander Lichter:

And there's another thing where there's no reason not to do it, which is coming around to the conference in Bonn, Germany, the Vue. Js de, conference.

Alexander Lichter:

If you wanna see amazing speakers like, Danny Rowe, a live q and a remote, but still there live with Avenue. Was also here, by the way, if you if you have missed it out. So amazing episodes with him. And and lots of lots of other amazing speakers, lightning talks, which is, the conference is in early October, and you get a whopping 10% discount with the lovely code, Deja View. Link for it also in the description.

Alexander Lichter:

So if you come around, please say hi. I'd love to to see you all around, and, looking forward to meet some of you.

Michael Thiessen:

And before we wrap up, I wanna give you the full details on Nuxt tips collection since I only gave a little bit of a teaser earlier on. So we've got a 117 tips in an ebook. And you don't just get this ebook, you also get emails every workday. So you get 2 tips every day. And I've had a lot of people tell me about the, Vue tips collection that I did in the past that, you know, you're working on one project, you get some tips in your inbox and then you realize, oh, wait, that thing is helping me with this thing I'm working on right now.

Michael Thiessen:

And that's pretty crazy. And so, that's a really nice feature. And there's the 7 code repos that you'll get as well. So you can play around some things and dig into some code. And it's launching August 5th, which might be in a few days from now, and it might be today, depending on when you're listening to this.

Michael Thiessen:

And if you or or yesterday or 3 days ago or okay. We've covered our basis there. You also can get an extra $10 off using the DejaVue code. So check it out. Link in the show notes description wherever you are.

Alexander Lichter:

Exactly. And last but not least, we want to know from all of you, besides if you have used the, the key auto key composables ever in Nuxt. If you do, as mentioned, tell us. And we want you to know what is your favorite, Nuxt Gem or Nuxt tip. What what would you say?

Alexander Lichter:

Like, it's something you found out, but, like, oh my god. Is this possible? That solves so many headaches, of course, besides Nuxt itself. So let us know. Let us know what, your favorite feature is that you're like, I can't live without this anymore.

Alexander Lichter:

It can be module. It doesn't have to be in the core. Yeah. Bring it on. Exactly.

Alexander Lichter:

Or one of later episodes, definitely check them out. And until then, stay tuned. See you around, folks.