Config

Everything there is to know about configuration files.

For the list of configurations, see:

+ files

You configure your Vike app by creating + files such as +config.js.

For example, you can set the Page and Layout settings of a page by defining +config.js:

// /pages/product/@id/+config.js
 
import Page from './Page'
import Layout from './Layout'
 
export default {
  Page,
  Layout
}
// /pages/product/@id/Page.js
 
export default /* ... */
// /pages/product/@id/Layout.js
 
export default /* ... */

For more convenience, you can do this instead:

// /pages/product/@id/+config.js
 
import Page from './Page'
import Layout from './Layout'
 
export default {
  Page,
  Layout
}
// /pages/product/@id/Page.js
// /pages/product/@id/+Page.js
 
export default /* ... */
// /pages/product/@id/Layout.js
// /pages/product/@id/+Layout.js
 
export default /* ... */

Both achieve the same: it's just convenience.

Except of +config.js, any + file corresponds to a Vike setting or a Vike hook.

Inheritance

You can apply configurations to all your pages, a group of pages, or only one page.

For example the Layout setting:

pages/(marketing)/index/+Page.js    # URL: /
pages/(marketing)/about/+Page.js    # URL: /about
# Layout for marketing pages
pages/(marketing)/+Layout.js
 
pages/admin-panel/index/+Page.js    # URL: /admin-panel
pages/admin-panel/users/+Page.js    # URL: /admin-panel/users
# Layout for admin pages
pages/admin-panel/+Layout.js
 
pages/product/@id/+Page.js
# Layout for the product page
pages/product/@id/+Layout.js

The directory (marketing) is used for grouping and is ignored by Filesystem Routing.

  • pages/(marketing)/+Layout.js applies to all pages living at pages/(marketing)/**
  • pages/admin-panel/+Layout.js applies to all pages living at pages/admin-panel/**
  • pages/product/@id/+Layout.js applies to one page pages/product/@id/+Page.js

    Technically pages/product/@id/+Layout.js applies to all pages at /pages/product/@id/** but there is only one page living there.

Defaults

You can set defaults and override them.

For example the ssr setting:

// pages/+config.js
 
export default {
  // Disable SSR by default
  ssr: false
}
// pages/(marketing)/+config.js
 
export default {
  // Enable SSR for marketing pages
  ssr: true
}

Cumulative configurations, such as <Layout>, don't get overriden. See #1692 - [Cumulative configs] New settings override and default.

Domain-driven File Structure

You can use a domain-driven file structure for an improved organization of your pages and their configurations.

Powerful

You can use multiple completely different rendering strategies for the same app.

For example, some pages can use Vue without SSR while other pages can use React with SSR:

// pages/admin/+config.js
 
import vikeVue from 'vike-vue/config'
 
// Admin pages using Vue without SSR
export default {
  ssr: false,
  extends: [vikeVue]
}
// pages/product/@id/+config.js
 
import vikeReact from 'vike-react/config'
 
// Product page using React with SSR
export default {
  ssr: true,
  extends: [vikeReact]
}

Pointer imports

Internally, Vike transforms this:

// /pages/+config.js
// Environment: config
 
import Layout from '../layouts/LayoutDefault.jsx'
 
export default {
  Layout
}

Into:

// /pages/+config.js
// Environment: config
 
import Layout from '../layouts/LayoutDefault.jsx'
const Layout = 'import:../layouts/LayoutDefault.jsx:default'
 
export default {
  Layout
}

This enables Vike to load the file /pages/+config.js without having to load LayoutDefault.jsx. This means that Vike can quickly load all your +config.js files without having to load any runtime code.

These fake imports, which we call pointer imports, apply only to +config.js files. Imports in other + files are normal imports as usual.

It's similar to when you import images:

import logo from '../images/logo.svg'
// When you import an image, you don't actually load it: you get a URL instead.
console.log(logo) // Prints: /assets/logo.svg

Vike transforms an import inside +config.js to be a pointer import if and only if it resolve to a .jsx file, a .vue file, or any other file that doesn't end with .js or .ts (or .mjs/.mts/.cjs/.cts). For example:

// /pages/ssr.js
// Environment: config
 
export default false
// /pages/+config.js
// Environment: config
 
// Resolves to the file LayoutDefault.jsx (a .jsx file) => pointer import
import Layout from '../layouts/LayoutDefault'
// Resolves to the file ssr.js (a .js file) => normal import
import ssr from './ssr'
 
console.log(Layout) // Prints: import:../layouts/LayoutDefault:default
console.log(ssr) // Prints: false
 
export default {
  Layout,
  ssr
}

A .jsx or .vue file is always meant to be client- / server-side runtime code. (I.e. it's never used for config logic.) That's why it makes sense that Vike always treats .jsx and .vue as pointer imports.

Manually mark pointer imports

You can manually mark an import to be a pointer import:

// /pages/+config.js
// Environment: config
 
import ssr from './ssr' with { type: 'pointer' }
console.log(ssr) // Prints: import:./ssr:default
🚧
The with { type: 'pointer' } import attribute isn't implement yet, see workaround at #1500.

Config code isn't runtime code

The config code in itself is never included in runtimes:

// /pages/some-page/+config.js
 
// A CSS import in a config file doesn't have any effect. CSS should
// be imported in runtime files such as +Page.js instead.
import './some.css'
 
// This log is printed only when Vike loads this +config.js file (at development, and when
// building your app). This log isn't included in the client nor server runtime.
// Consequently, you won't see this log in production.
console.log("I will never be logged in production")

See also