Next 13/14 App Router Issue

[headline-design]

Describe the bug

So this is an issue and solution we have encountered with Vanilla Extract and App Router - Next13/14. Everything looks fine in development, but as soon as you go to build the application, styles are no longer applied correctly. The classnames are set correctly but the specificity is all screwed up. Basically, what appears to be happening is that the Next build system is placing the wrong styles at the top of the stack. After quite a bit of digging, what we discovered was that the issue could be resolved by removing the reset/default style for the Box element. Anyone working with a design system and encounters this problem can try the remove reset solution. It's more of a temp solution, but it fixed the issue. We tried this with at least a dozen different configurations of versions for vanilla extract and next. This is specificaly an issue on app router, no such issues on pages router.

Reproduction

n/a.

System Info

vanilla-extract
next 13/14

Used Package Manager

yarn

Logs

No response

Validations

• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• The provided reproduction is a minimal reproducible example of the bug.

[askoufis]

@headline-design This could likely be the result of next loading styles out of order in dev mode vs production (not something we can really fix on our end). I think the issue here might not be your actual reset styles, but rather the order you're importing them.

In dev they just happened to be correct, but in prod the order your modules resolve dictates the stylesheet order. Are you importing your reset styles at the top of your app? If you just rely on your Box component to import the reset styles, then they might not end up at the top of your stylesheet, depending on where the first Box component is resolved in your app.

Alternatively, scoping your reset styles to a cascade layer can help.

[rnacken]

I ran into a similar issue.
I think @askoufis is correct that it not the reset-styles per se, but that they are loaded in a different order in production vs in dev mode.
We already used layers, but I noticed we still had problems. I guess this is due to the way VE sets up the order of the layers.

We use this in our code:

import { globalLayer } from '@vanilla-extract/css';

export const resetLayer = globalLayer('reset');
export const baseLayer = globalLayer('base');
export const uiPrimitivesBaseLayer = globalLayer('uiPrimitivesBase');
export const uiPrimitivesPropsLayer = globalLayer('uiPrimitivesProps');
export const uiCompositesLayer = globalLayer('uiComposites');
export const sectionLayer = globalLayer('section');

In dev-mode this works well (checking the dev-tools in Chrome):

But on production you'll see the order all wrong:

I could fix this by writing a small script (in the root folder) that prepends the correct order of the layers in all generated css-files, like this:

// fix-build-css.js
/**
 * Small script to prepend the correct layer-order into each generated css-file for NextJS Builds
 * This is necessary because the Vanilla-extract files are loaded out of order during production-build, which will screw up the layer-ordering
 */
const fs = require('fs');
const path = require('path');

const cssFilesPath = path.posix.join(
	__dirname,
	`.next`,
	'static/css'
);

const cssLayerFixStyle =
	'@layer reset, base, uiPrimitivesBase, uiPrimitivesProps, uiComposites, section;\n';

const fixCssFiles = async () => {
	const folderContent = await fs.readdirSync(cssFilesPath);
	const cssFiles = folderContent.filter(
		(item) => path.extname(item) === '.css'
	);
	cssFiles.forEach((filename) => {
		const filepath = path.posix.join(cssFilesPath, filename);
		const cssContent = fs.readFileSync(filepath);
		fs.writeFileSync(filepath, cssLayerFixStyle + cssContent);
	});

	console.log('fixed Vanilla Extract build css-files');
};

fixCssFiles();

And trigger this script after each prod-build like this:

// package.json
"build: next build && yarn fix-build-css.js"

It works, but I am very unhappy of course with this 'solution' and would love to see some guidance of VE-team on how to fix this better?

[askoufis]

@headline-design Could you please try out v2.4.0 of the next plugin to see if that addresses any of your issue? If it doesn't, it would really help if you could provide a minimal reproduction.

@rnacken I can't reproduce your out-of-order layers bug with the latest next plugin. Not sure if this was because of the fixes in that version, or other fixes on the next side. Could be related to #1112.

[rnacken]

@askoufis Sorry it took a while; can confirm - it works now. Thanks

[askoufis]

@askoufis Sorry it took a while; can confirm - it works now. Thanks

All good, thanks for following up!

@headline-design Any update from your end?