Since most Nuxt layers are meant to be reusable across multiple projects, it only makes sense that you should have the ability to configure them with options based on the need of the project. The way that that is set up to be done inside of the template for a layer is via the app config file. The convention is to name a property inside of this app config to the same name as your layer, and then provide a value of all your layer's options. You can even make this type safe by declaring the at next schema module and modifying the app config input interface with your layers options.
ts of the end application, you can override any of the defaults for your layer with an auto-completable type safe my layer property. This works great for a lot of your configuration needs. However, there's one very important caveat. All of this configuration gets bundled into your JavaScript output and ultimately makes its way to the browser.
In my running application, if I inspect the dev tools, filter based on JavaScript files, and then refresh my page, let's see here. Yep, sure enough, here is that app config, and there are all of our configuration options available for the world to see. Now, in the published app, of course, this wouldn't be its own individual file. It would be bundled into the final bundle, but it's still available for the public.
That means you cannot use app config to define private configuration options for your layer. In fact, it says as much about app config in the official Nuxt docs. So how can we provide private configuration options for our layers? Well, the exact same way we provide private runtime variables for our Nuxt apps, via runtime config.
ts, I'm going to copy this TypeScript statement here so I can easily modify it to type our runtime config. ts file inside of our layer, let's paste in that module declaration and change out appconfig input to runtime config. Now we can define a property for our layer, just like we did with the app config, but then expose private options that'll only be seen on the server side. config of the end user application, we could override it to set custom values.
In combination, both of these configuration methods have you covered for all your layer's configuration needs. One little gotcha to look out for when you're declaring your types for these configuration options is do just make sure that your layer's key inside of runtime config is an optional property. And same thing for the app config. That way, the consumer of the layer doesn't have to set any configuration options in either place if they're cool with the defaults.