Using Stylify CSS in Next.js

Next.js offers you to create production grade React applications that scale.

Stylify can be easily integrated into the Next.js using @stylify/unplugin.

Try it on StackBlitz

How to integrate the Stylify CSS into the Next.js

First, install the @stylify/bundler package using NPM or Yarn:

npm i -D @stylify/unplugin
yarn add -D @stylify/unplugin

Next add a configuration into the next.config.js:

const { stylifyWebpack } = require('@stylify/unplugin');

const stylifyPlugin = (dev) => stylifyWebpack({
    dev: dev,
    bundles: [{ outputFile: './styles/stylify.css', files: ['./pages/**/*.js'] }],
    // Optional
    // Compiler config info
    compiler: {
        variables: {},
        macros: {},
        components: {},
        // ...

module.exports = {
  reactStrictMode: true,
  webpack: (config, { dev }) => {
    return config;

And the last step is to add the stylify.css into the _app.js:

import '../styles/globals.css';
import '../styles/stylify.css';

function MyApp({ Component, pageProps }) {
  return <Component {...pageProps} />

export default MyApp;

Now you can use the Next.js commands to build your assets. In production, it will mangle selectors.

Production Build and Selectors Mangling

When you run yarn dev/npm run dev (which often runs next dev) during a development, selector are going to be generated in the same way as they are written in the class attributes.

In production build, that is executed by yarn build/npm run build (which often runs next build), selectors are minified from long color:blue to short a.

Selectors are rewritten directly within files/templates. This is because Stylify matches selectors only in selected areas (to prevent unwanted characters to be matched) like class, className, :class. However, frameworks compiles these attributes like class="color:blue" to something like add_attribute(button, "class", "color:blue") under the hood.

This can cause, that some original selectors will not be rewritten because they are not matched. Stylify could have matching areas defined for frameworks' compiled output, but this could break with any release. Therefore is safer to rewrite them directly within templates during a production build, where it takes no effect on development environment because this command is mostly executed in build pipeline in Github/Gitlab or during a Vercel/Netlify build and deploy.

How to disable mangling and selectors rewritting

If you want to disable mangling, for example for testing production build locally or even in production build, just add the following into the config:

const stylifyPlugin = stylifyWebpack({
	// ...
	bundles: [ /* */ ],
	compiler: {
		mangleSelectors: false

Sometime, the class attribute can be consistent during the build within the bundler (it's random). You may try to disable rewriting selectors within files like this:

const stylifyPlugin = stylifyWebpack({
	bundles: [
			// ...
			rewriteSelectorsInFiles: false

If selectors are rewritten correctly even after this configuration, you can keep it that way. Otherwise, if you still want the rewriting to be disabled, you will have to dig into Stylify Compiler rewriteSelectors method and see what comes as an input into this method and configure a correct selectorsArea, so Stylify can process it correctly.

Selectors mangling in files cannot be disabled in frameworks that are not based on Javascript (PHP, C#, Java), because their templates are not compiled by Vite/Webpack/Rollup/ESbuild.

Where to go next?