In this lesson, let's talk about how I bundled the Mail Catcher DevTools with my layer. If you head on over to the DevTools website, check out the documentation, and then come to the module authors page, you can see that you can contribute a view to the DevTools. And really all it is is an eye frame that you display some content in within the dev tools window. The function that allows you to do that is called add custom tab and it comes from the next dev tools kit.
So that means we do need to make sure we have the next dev tools kit installed in our project, which I have or We could also choose to use the DevTools custom tabs hook. Then we just push a new tab, giving it some name. So some unique identifier. I think I used the layer name itself.
Let's head on over to my code and let's just take a look at it there. So inside of my layer and then inside of a module that lives in my layer. So this is a really cool thing. We can actually have layers use modules.
And then when we shut the layer, all those modules go with it too. That is super, super cool. But anyways, here I have a male dev tools module. The main definition of that module doesn't do much.
All it does is define the module, give it a name and a config key. Then it grabs the resolver using the create resolver function, which is imported from NuxtKit. devtools is enabled and we're in development mode, then let's set up our DevTools UI for the mail catcher. ts.
And you can see right here, this is exactly what they were doing in the docs. We're hooking into that DevTools custom tabs event, and then we're pushing a new tab. The identifier is email DevTools, so I didn't prefix it with layer. Maybe I should have.
The title is just a string of email. The icon is mdi colon email. This is an iconify icon selector, but you could also use a URL to any image. And then we have the view, which is nothing but an iframe that we want to display in the DevTools window.
So all of that is super easy. The trick now, though, is where do we want the source of that iframe to point? Well, originally I had my DevTools UI just as another page in the main application. In other words, inside of my layer and then an app and then pages, I created a page that had all the UI on there for this right here.
And then I just set the source to my main application's dev server and expose it on a certain page. The problem with that, though, is it wouldn't work if you didn't have view router installed in the end application. vue file without the pages directory. So what I did instead and what I've seen other people do inside of their custom dev tools is spin up a brand new Nuxt dev server.
That's what this function right here is doing. Start dev tools server. What does that look like? Well, first of all, we just resolve the path to the server app that we want to boot up.
Let me remove this pages directory that I just put in as an example. And then if I go under modules, mail DevTools, you'll see this DevTools client folder. And it's just another little tiny Nuxt app. That's what this client path is pointing to.
This is a whole little Nuxt app just for this interface right here. The next thing we do is listen for the main dev server to boot up so that we can capture the port that it is running on. Then if our custom dev server, if our DevTools dev server hasn't started yet, which it probably hasn't, then we go ahead and start it up. What does starting up the dev server look like?
Well, it's a function here that just first checks, does the main server port exist? Is that set? If it's not, throw in error. Otherwise, let's spawn a brand new command.
What's the command? Well, npx nuxedev, of course, with a port that we've hard-coded into this process, meaning, yes, you can only have one mail catcher server running at a time. Maybe there's a way we could clean this up and make it more dynamic, but this works for now. Then we set the current working directory to that client path.
We set the standard input output to ignore, so we don't get any feedback on this process in our main dev server running process. add all the env variables that are currently in env but we add this main server port that way we know what port our main dev server is is running on that'll be useful in just a moment okay so now we've started this dev server the separate nux dev server Finally, right here, we just check to see, well, if the main server port exists, let's start the dev server again. Not really again. This is just kind of a safety net in case this listen doesn't fire quite like we thought it would.
But the last thing that's really important here is that we also kill this extra dev server whenever the main server stops. Awesome. So what exactly is this main server report for? config in my little mini Nuxt app here, notice that I'm targeting Vite server proxy, and then I am proxying all the requests to slash API to my main development server.
Why? so that when we make any request to the API in the dev tools to do things like send a new email or delete an email or refresh the listings here, we're actually going to the API endpoints that are defined in our layer. You might think we could just move these API endpoints into our little mini app, But then these API endpoints wouldn't get the email layer configurations and storage base configuration from the consuming app. So it was important that we kept these API endpoints in the layer code so that they go to the main consuming app.
Awesome. That's pretty much all there is to creating this custom dev tool. The last little bit that's worth mentioning is that there is a dedicated DevTools UI kit. It can be installed as a Nuxt module.
Of course, we only need it in our little mini Nuxt dev server here that powers the DevTools. vue, that's exactly what I'm using to display the UI. If you want to learn more about that UI library, check out the Nuxt DevTools webpage. It has a UI kit page dedicated to just that.