Now that we had an in-depth look at the fascinating world of Nuxt modules, it's coding time. We're going to create your very first Nuxt 3 module from scratch. A module can be part of your application files inside your modules directory. This is called a local module, or it can be a separate entity published as a package, which you can grab and install in your app.
In our course, we will cover both local and published modules. Let's start with local modules. I'll create a new directory first, then head inside, create a new NuX project, and I'll go with yarn, no need for a get repository, and then let's head inside. Inside our project root, we create a new directory called modules, and this is where all our modules will be.
Let's open our app in VS Code. A small tip by the way, we can do that directly from the terminal by typing code and then dot, to represent the current directory, but this won't work unless you do something first in VS Code. You will have to install vs command. You do that by opening VS Code, then opening the command palette using command shift p on mac, then install code.
I have that already installed so no need for me to do that, but you can do this and once you're finished you can just go back to the terminal, hit code dot and then enter This will open the project in VS Code. ts So it's totally up to you whether you would like to define your module entry points directly inside the modules directory or you would like each module to be in a separate directory. I'll go ahead and delete all those ones that we created and create a new module. Let's call it first module.
And now you're totally free to choose whether you'd like it to be a TypeScript file or JavaScript file, but I'll use JavaScript in this example. A low-level module definition would be a simple function. Something like this. Export, default, function.
And that's it. Or it can be an async function as well. So it can look like this. And this is a low-level module definition.
All your logic will go here. This function will run as soon as we run dev or production server. So let's console log a message and see what happens. I'll hit command S to save the file.
ts, we have DevTools set to Enabled. So from within our module, we can change this. We can manipulate the option and set it to false. And doing this is actually quite easy.
I'll terminate the running development server, exit the terminal and head to our module. And now let's delete this console lark and start thinking about it. Our module function parameters are passing two things. The first parameter is inline options.
Inline options. And in our case, we're not passing any options to the module, so it will evaluate to an empty object. The second parameter is a Nuxt object. And with this Nuxt parameter, the module will allow us to communicate with the running Nuxt instance.
So let's turn off the DevTools option. The Nuxt parameter will give us access to Nuxt options. And inside Nuxt Options, the option we want to tweak is the DevTools option. Inside of it, there is a property called Enabled.
We need to set that to False. So, DevTools, Enabled, False. And then let's console log some message. Something like, I disabled the DevTools.
And let's see if that worked. It works. Here is our message. And if we visit Chrome, refresh, we shouldn't see the DevTools.
And it doesn't exist anymore. And if we comment out what we have just did, like so, wait for the application to rebuild, then visit Chrome again, hit refresh, we will see the DevTools again. ts file from within our module. So let's uncomment that again, wait for the application to rebuild, and the DevTools should disappear as soon as we refresh.
And it's gone again. we can run as many modules as we want inside our app and each module will have a set of tasks that will be fulfilled during build time. Let's keep playing with our modules then. I'll create another module and I'll define a function just like this passing inline options and next object.
So this is the entry point for the another module. And inside that I would like to revert the action that I've done in the first module, so I would like to enable the DevTools again. So next, options, DevTools, and set enabled to true again. So this should enable the DevTools again.
Let's console log a message, something like I enabled the DevTools again. And let's see how that goes. Yarn Dev, and if this worked as expected, we should see the DevTools again. But we don't.
Which means that it didn't work. And looking at the terminal, looks like that I enabled the DevTools again locked to the terminal before I disabled the DevTools. Which is very strange, because this is the second module that we created, which is the another module. So the first module should be triggered first, but it didn't.
Okay, here's the thing. This is happening because the modules inside the modules directory will run in a sequentially alphabetical order. So the module starts with the letter A, will run before the module that starts with the letter F. But in our case, we really want the another module over here to override the first module behavior.
So the another module would enable again the DevTools. How can we make this work? Well, luckily Nox provides a way to control the order of modules by adding a number before its name, so it will go like this. Now let's check on our app, hit refresh, and here is the DevTools working again, which is the same order that we expected.
I'll close the terminal for now and delete the second or the another module that we just created, and get back to the first one. I'll delete that code as well, and let's start fresh. ts. Press Enter.
We'll notice that the parameters are highlighted in red. If we check the errors, it's because we didn't define any types for them. Well, here is when NoxCat comes to the rescue. We will use NoxCat a lot in this course and we will get to know it in details.
For now, just consider it as your indispensable set of tools while tweaking things in Nuxt, especially from Nuxt modules. Whenever you need anything, you just import the toolkit, grab what you need, and in our case by the way, it's the defineNuxtModule function, and we will export that instead. So, let's do this, like so, and convert it to an arrow function. We're good to go.
All that time, even now, we've been using Noxed modules as low-level functions, but we're missing a lot by doing so. Noxed provides a high-level way to define modules. It's also the recommended way by Noxed team. We will still use defineNoxedModule function, but we will tweak the implementation of the function to the new object syntax.
I'll comment the old syntax out and use the new one, which is export default. DefineNoxedModule again. but this time we're passing an object. Inside that object there is setup function that will be passing module options and next object as parameters.
And then right here you can write down whatever the code you would like to run in your module. With this beautiful syntax we get type hence and automated type interface and it also provides us with extremely useful properties inside that object. We get to define the meta property like so. And inside this Meta property, we can add a name for the module.
Usually, you set this to the npm package name of your module. Even though this is a local module, it's a good practice to provide the name anyway. This is because Noxt under the hood uses MetaName or MetaConfigKey. ConfigKey is another property that we will introduce in a minute.
Anyway, it uses both of those keys to create a computed unique key for the module and this will ensure that the module is only installed once in the application. ts file to pass options to our module so it will look like this first module and then pass whatever options you would like to pass to the first module. Awesome! The Define Nuxt module also has a property for compatibility.
And here you can specify semantic versioning of supported Nuxt versions. As Nuxt will use that info to automatically check for compatibility issues. All you have to do is just add Nuxt property and that desired version. 0 for example.
We also have the defaults property. This will hold the default configuration options for our module. And the cool thing about Nox3 object syntax modules is that the default options defined here are automatically merged with the options defined by the user using the config key. So in our case if the user defined any options here in the first module config key then it will be automatically merged with whatever defaults we will apply here.
We have one more property which is the hooks property and this is just a shorthand to register noxed hooks. Alright then, I know that we have gone through the properties very quickly, but don't worry about it, we will have plenty of time to practice. So that wraps it for this lesson, and in the next one, we will take our module to the next level.