When you're focused on a specific app and the logic for the module is only needed there, local modules work just fine. However, if you aim to use your module across multiple apps or contribute to the Nuxt modules ecosystem, publishing your module is the way to go. The process is a bit different from working with local modules though. We will clean our application from the modules we created in the previous lesson and just leave it for now.
Okay. So working with Nuxt feels like Nuxt core team main mission is to make developers lives easier. Instead of preparing npm package from scratch, then install dependencies and dev dependencies, structure your directories and all of that work. The Nuxt ecosystem offers a fantastic starter template that will take care of everything for you.
And it's not only about modules. It provides a starter templates for Nuxt 3, Nuxt 2, Bridge, UI. And we actually used it in a previous lesson when setting up Nuxt content. So I'll copy the command for the medjool template and start exploring.
So I'll paste it here, but let's give it another name. Something like View School Medjool. I'll go with yarn. I don't need a get repository, so no.
I'll clear that up. Then head inside. Open DS Code. Now let's find out what is this starter template all about.
json file, we will notice that everything is already pre-prepared for us. I mean, entry points, types, scripts to get you started faster, dependencies and dev dependencies. So it takes away all the boring things that you need to do to start an npm package from scratch. So let's make sure that we have all the dependencies installed.
And before we continue our exploration, there is another important script that we need to run, which is DevPrepare. More on that later, but this is preparing the dev environment for you to work with including types, playground and everything else. So yarn dev prepare Now we're good to go. It also has an ESLint configuration file that extends Nuxt ESLint config package and as you notice it's starting with at Nuxt which means that it is an official package made by the core team and it has a dedicated test directory And this test directory has a basic test made with vtest to help you get started with testing.
This sounded a bit like I'm rapping. Anyway, the test here is against a Nuxt app with the module installed in it. And it's checking if the server is responding with the correct HTML when the index page is requested. json file, which is the test command.
So let's open up a terminal and then yarn test. and enjoy the elegance of testing with vtest. Oh, and by the way, we got an amazing course about vtest made by Anthony Foo. He is the creator of vtest, viewuse, and our Noxcore team member.
Feel free to check that out if you're interested in learning more about testing. Now, let's continue and check out the src directory. Here is where all the magic happens. ts file is the starting point for the Majol.
If we take a look inside, You will notice that the code is a bit familiar to you from the previous lesson. Define Nuxt module is imported and the module is using the object syntax. The meta property has the name and the config key defined. The defaults option is empty, then the setup function has the logic.
The only strangers here are addPlugin and createResolver. The createResolver from Nuxtcat is resolving the path for a file in the runtime directory. It's a good time to make it clear that modules aren't automatically included in your application runtime, but Nox team was aware that there might be some cases where developers want the module to inject runtime code into the application it's installed on. That's where the runtime directory comes into play.
Inside this directory, you can include various assets related to the Nox app such as view components, composables, and Nox plugins. Here, a plugin is being injected using the addPlugin function from the runtime plugin directory. But don't worry about this for now, we will discuss plugins and most of NuxtKit utilities in details later in the course. Now, jumping to the Playground directory, it serves as a Nuxt app ready to use as a Playground.
An incredibly handy feature that saves a lot of time. ts file, you will notice that the module's property explicitly registering the module. It doesn't auto-register the module as it typically does with local modules. This is happening because the module resides outside of the module's directory and outside of Nuxt's app root.
The Starter Templates Playground is designed for testing modules as published entities rather than local ones. That's why the module is outside of the Nuxt app root and is required to be manually registered in Nuxt config. And when we run the dev server for the Playground app and open the site, the plugin added by the module from the runtime directory should log the message to the console. So, once the site is open, the message will pop in the terminal.
One more thing to add, if we head inside the directory, we are inside Nox app where all Noxie commands can work. So let's prove this. I'll head to Nox documentation and pick a command from there. API Commands.
And we can pick one from this list. I'll go for Noxie Cleanup. We can run npx-noxie-cleanup which removes common generated Nox files and cache, and that would work exactly like it would in a real Nox application. ts file in the clean playground directory will spot typing errors immediately, because we just deleted all the generated types in the app.
Don't worry, we can easily fix this. json file. As we mentioned earlier, all the scripts here are very important, but the DevPrepare script is the most important one during the development phase. See this NoxedMajulBuild build?
This is what builds the module and bundles it for production and publishing. This command is coming from the official package NoxedMajulBuilder. Remember when we said that Nuxt official packages are prefixed with at-nuxt? So the module builder package is an official Nuxt package developed by the core team to help us bundle our modules.
Let's have a quick look at the github repository for this project. com nuxt-module-builder So let's go to the redmi file and there you go. As listed here, it's full of features that's helping us with creating our modules, like automated building config, TypeScript and ESM support, but I'll just zoom in a little bit, scroll all the way down, and that's what I really wanted to show you, the dest files. The module builder generates dest files in the dest directory.
ts file should be gone. So let's head that. Okay, I'll close the file, open it again, and it's gone. That's great!
Now, let's head back to Package to JSON file because I want to show you a cool trick. Let's imagine a scenario where you don't want to use the Playground to test your module. Maybe you have your own Nuxt app locally, and that's what you really want to test. In that case, we can add a new script to the root package to JSON file.
Let's name it link, and that will be npm link, which will basically create a symlink to the package, in our case it's the my-module package that represents the module. And then we can go back to the other project and add another script, let's name it link-module, and that will link our project with the my-module package so it would be npm link-my-module. This will make our module package work in our Nuxt app as if it was an installed package. config file and before doing anything on the Nuxt application we want to use, we must head back to the module package, create the same link by running the script that we just created and once that is done, we can now link to this package from our Nuxt application.
The linking process will look exactly like as if you're installing a package. And once that is done, we can run a dev environment and see if that works. We are in the Nuxt app without a modules directory, but if we run the application and take a look at the terminal, we will see the message that is injected to our application runtime from within the module, which is right there. Okay, so I want to squeeze one final thing to this lesson.
which is publishing your module. com and login with npm login command and you could use npm publish command to publish your package but you would be missing a lot. The Starter Simplet has a release script which handles a lot of things for you like linting, testing, building the module and if everything went as expected it will then bump the version and generate the changelog. So far in the course we explored local modules and the official module starter kit, but in the next lesson we will expand Noxed modules capabilities.
But just before you go, I know you thought we're finished, but I got something for you. Here is a small exercise to get you ready for the next journey. com, click on Roboto, select the black 900 italic. It will provide you with view lengths that you need to include in the document's head.
Now, use the module you just created to inject those lengths in the head of your Playground application. view, if you succeed it, once you add these tiles, the new font should take effect. Here is a tiny hint. If you check the documentation, you will see that with the next options, there is an app property, and that has head link properties.
You can push link object from the module to the link array and next we'll include those links in the head. I hope you'll enjoy solving this exercise.