custom properties of themes don't work in vite production build

[pat-rickster]

Hi, when I build my app in production mode with vite, the custom properties of the themes (colors etc) don't work. In the devtools of the browser it says they are not set, which isn't true. It doesn't matter if I use a custom theme or a standard theme (e.g. 'light'). When I'm starting the app in dev mode, the layers with the custom properties are working. I'm using vuetify version 4.0.7, vite 8.0.10 and vue 3.5.33

[mg1986jp]

This is usually a Vite CSS extraction issue. In dev mode, Vite injects styles via JS (which preserves insertion order), but in production it extracts CSS into files where the ordering can change.

A few things to check:

1. Are you using vite-plugin-vuetify? It's required for proper style handling in production:

// vite.config.ts
import vuetify from 'vite-plugin-vuetify'

export default defineConfig({
  plugins: [
    vue(),
    vuetify({ autoImport: true }),
  ],
})

2. Check if your main.ts imports Vuetify's styles in the right order — the theme CSS needs to load before any component styles:

import 'vuetify/styles'
import { createVuetify } from 'vuetify'

3. After building, open the generated CSS file and search for your custom property names. If they're there but not applied, it's a specificity/layer issue. If they're missing entirely, the plugin isn't extracting them.

4. Try adding css: { devSourcemap: true } in your Vite config and inspect the production build — sometimes CSS chunks load in the wrong order.

Can you share your vite.config.ts and how you're defining the theme? That would narrow it down.

[pat-rickster]

Hi @mg1986jp, thanks for the reply. We were able to identify the problem: It was a configuration in the CSP header that prevented runtime bundling. If we set style-src 'self' 'unsafe-inline'; it works. But I don't know if it's a practical solution.

Here's my vite.config.ts:

import { fileURLToPath, URL } from 'node:url'
import { defineConfig, type PluginOption } from 'vite'
import vue from '@vitejs/plugin-vue'
import vuetify from 'vite-plugin-vuetify'
import checker from 'vite-plugin-checker'
import { visualizer } from 'rollup-plugin-visualizer'

export default defineConfig({
  plugins: [
    visualizer({
      template: 'sunburst', // or treemap
      open: false,
      gzipSize: true,
      brotliSize: true,
      filename: 'bundle-size-analyse.html' // will be saved in project's root
    }) as PluginOption,
    vue(),
    vuetify(),
    !process.env.VITEST
      ? checker({
          vueTsc: {
            tsconfigPath: 'tsconfig.vitest.json'
          },
          eslint: {
            useFlatConfig: true,
            lintCommand: 'eslint "./src/**/*.{vue,js,jsx,cjs,mjs,ts,tsx,cts,mts}" --no-fix'
          }
        })
      : undefined
  ],
  resolve: {
    alias: {
      '@': fileURLToPath(new URL('./src', import.meta.url))
    }
  },
  build: {
    minify: 'terser',
    assetsInlineLimit: 0,
    terserOptions: {
      format: {
        comments: false
      }
    },
    sourcemap: false
  },
  server: {
    port: 8095
  },
  base: '/spa/',
  define: {
    __INTLIFY_JIT_COMPILATION__: true,
    __VUE_I18N_LEGACY_API__: false
  }
})

[mg1986jp]

@pat-rickster Glad you found it. CSP blocking inline styles makes sense — Vuetify injects some styles at runtime via <style> tags, and without unsafe-inline those get blocked silently.

unsafe-inline works but weakens your CSP. A cleaner option: Vuetify supports a cspNonce option that adds a nonce to its injected styles, so you can allow them without opening up all inline styles:

const vuetify = createVuetify({
  theme: {
    cspNonce: 'your-generated-nonce',
  },
})

Then in your CSP header: style-src 'self' 'nonce-your-generated-nonce' instead of 'unsafe-inline'. You'd generate the nonce per-request on the server side.

If that's too much plumbing for your setup, unsafe-inline for style-src only is a reasonable tradeoff — it's script-src 'unsafe-inline' that's the real security concern.

[MILLERMARRU]

unsafe-inline isn't your only option here, Vuetify has a documented cspNonce setting made exactly for this:

import { createVuetify } from 'vuetify'

export const vuetify = createVuetify({
  theme: {
    cspNonce: 'dQw4w9WgXcQ', // must match your CSP header's nonce
  },
})

Content-Security-Policy: style-src 'self' 'nonce-dQw4w9WgXcQ'

Vuetify's theme system injects its computed CSS variables via a <style> tag at runtime (that's why it broke the moment your CSP stopped allowing inline styles), cspNonce tells it to stamp that tag with the nonce so your policy can allow it without opening the door to arbitrary injected styles.

One thing to get right given this is a Vite SPA rather than an SSR app: a nonce only provides real protection if it's fresh per page load/request and matches what's in the CSP header at that moment. If you hardcode a static nonce string at build time, you've effectively rebuilt unsafe-inline with extra steps, since an attacker who can see your one unchanging nonce (it's right there in your shipped JS) can reuse it. For this to be meaningful, your server or edge/proxy needs to generate a new nonce per request, inject it into the CSP response header, and hand that same value to the client (a <meta name="csp-nonce" content="..."> tag rendered server-side is the usual way) so createVuetify can read it at runtime instead of having it baked into the bundle.