Picking up from where we left, we'll start this one by solving the problem introduced in the last lesson. Which is that we're not giving our users the privilege to choose which option do they want to enable or disable. Let's solve that then. First, we need to set some default options in the defaults property right here.
This will be used as fallback options in case the user didn't pass any to the module. But before adding our defaults, let's first update the module options interface to avoid having TypeScript yelling at us. So the first feature in our module is the esbuild feature to disable console logs in production. So I'll call this drop console.
And this should be a boolean. Fine, what's next? It is the compress public assets for Nitro. So I'll call this one Nitro compress.
assets, for example. And that's a boolean as well, all of them are booleans. And the third one is the Manify, so that will be also Nitro, Manify, a boolean. And then finally, it's the experimental feature to disable the deep inside async data, useAsyncDataComposable.
So this I will call DisableDeepUseAsyncData. That's a long one. Cool. We are just getting started and TypeScript is already yelling at us.
It's telling us hey you need to set defaults options because it shouldn't be empty. So let's start with drop console and that should be true by default and same for all of them by the way. So I can just copy all of that over here, paste it like this and then replace that with a comma like so. Replace boolean with true for all of them.
Save. And we're good to go. Now we can perform some if conditions to conditionally implement each feature. The DefineNoxModule object syntax will take care of merging the defaults that we just added with the user options that will be passed.
And everything will be handed to us in the options parameter. So this will combine both our defaults with the user's options. Now let's wrap the esbuild stuff with an if statement so it will go like this if and then we say options drop console so if the user options or the default options evaluates to true for drop console we want this to be executed same for nitro compress assets so another if condition and then options nitro compress assets and then let's move that over here and save You got the point, so I'm just gonna do this quickly. And before doing anything else, let's just make sure that everything works.
So I'll head to AppTut view and ensure that we're throwing something to the console. Then we're going to build and preview the app. Let's hit refresh and nothing is being blocked. Okay, so everything still works.
That's good news. I'll close the terminal and let's use the medial config key which is basic optimizer. ts file. Basic optimizer, then drop console false.
And it should also work if it's inline options, like so. Let's just delete the config key and then pass it as an inline option inside the module array, like so. If everything went as expected, then we should start seeing the message in the console. Let's have a look.
There it is. Not only we can alter NoxConfig options, but we can also expose the module options to the Nox application runtime. Let me first just close the terminal and head to our module. We would need to import the third-party package called dfoo or at least this is just how I'm saying it.
And this package is used just in case the user already had the same key defined in the application runtime config. which is very unlikely because most probably your module will have a unique config key like this one but just in case who knows so let's go down there and expose the module options to the application runtime just like what we do with everything that has anything to do with Nox options we access NoxedOptions property but this time we're accessing the runtime config property public basic optimizer we will set that to default and then the first parameter it's going to be the same thing over here or an empty object and the second parameter we're just going to spread the options inside an object this will safely merge the options that we have in the module with the runtime config options and by doing so we successfully expose the module options to the runtime config public property which is really cool because now we can enable our users to pass options to the module using the runtime config public property so let's set the merged options to a variable called module options with the type module options and do the same thing we did before which is setting our key in the runtime config public property to the merged options using default which is now module options until now nothing changed at all but we can use this variable instead of using this options property directly. So if we replace all of them like this, it will allow our users to get rid of this and pass options to the module using the runtime config, public, basic optimizer. I'll go ahead and disable drop console and quickly disable all the other options.
view and change the message to show me the options and we will grab the options from the use runtime config public and our module key which is basic optimizer. Let's save and see if it worked and it did. Like you see here in the console all the options has been changed but of course we need to be careful not to expose any sensitive data like API keys for example. In the next lesson we will harness the power of Noxed Hooks from within our module.