Introduction

Background

Site config aims to be to things:

• A single source of truth for site config, for end-users and module authors. Site config can be considered config that is commonly used amongst modules but is not supported by the Nuxt core.
• A set of APIs for working with "writeable runtime config", for end-users and module authors.

Features

• 😌 Zero-config, best practice site config defaults
• 🎨 Site config from any source: Nuxt Config, Runtime Config, Environment Variables, App Config, Route Rules or Programmatically
• 🚀 Powerful and runtime agnostic APIs for module authors useSiteConfig, createSitePathResolver, withSiteUrl, useNitroOrigin, etc
• 🤖 Ledger capabilities
• 🤝 Integrates with @nuxtjs/i18n

Site Config Examples

url

A canonical site URL is important for SEO and performance

env

The environment the site is running in, importing so we can disable indexing for non-production environments.

See this issue on why we can't use process.env.NODE_ENV.

indexable

Can the site be indexed by search engines? Sometimes we have production sites that we don't want to be indexed.

name

The name of the site is often used in meta tags and other SEO related tags

trailingSlash

Trailing slashes are important for SEO and performance.

What's the problem?

Not having a single source of truth for site config can be difficult to maintain and error-prone, for end-users and module authors.

Requiring a lot of duplication and boilerplate code to support the same features across modules.

Nuxt Site Config aims to unify the experience of site config with a set of powerful and flexible APIs for end-users and module authors.

Can't we just use the Request URL or module config?

Nuxt itself provides a great SSR utility for getting the site URL from the request headers at runtime.

However, this has two major drawbacks:

• It's not available at build time or when prerendering
• When used for SEO content, it can cause duplicate content issues if the URL is not the canonical URL (e.g. www.example.com and example.com)

Can't we just use site on Runtime / App Config?

Yes. In fact, this module uses site on the App Config and Nuxt Config under the hood.

This module acts as a wrapper around these data sources, as well as:

• Environment variables
• Runtime Config
• Route Rules

It aims to keep all these in sync, resulting in a single source of truth for site config.

How does it work?

See How it works for more details.

End goal

We should be able to spin up multi-tenant or multi-lingual Nuxt app with minimal effort, and Nuxt modules should just work, without any additional configuration.

This is quite far off, but it sets a good direction for the module.