@import in used as a signal by build tools to bundle CSS.
It is however important in my opinion that this is done in ways that match native browser behavior.

Without this parallel users of such tools become dependent on the tool itself, and the tool becomes a barrier to entry for new users.

When implementations differ between browsers and tools there is an increased chance that implementations will differ between multiple tools as well. This also blurs the line between feature and bug.

These tests are intended to surface such differences.

Currently this checks :

• chrome
• firefox
• esbuild
• lightningcss (abbr. ⚡️)
• bun
• @csstools/postcss-bundler (abbr. p-bundler)
• postcss-import (abbr. p-import)

No config needed to make it compliant.

const esBundle = await esbuild.build({
	entryPoints: ['style.css'],
	bundle: true,
	logLevel: 'silent',
	write: false,
	external: ['*.png'] /* for sub-resource tests */,
})

Some config is needed to make it run without fatal errors.

let { code } = lightningcss({
	filename: 'style.css',
	errorRecovery: true, /* The CSS language is intended to be forgiving */
});

Still experimental. Fails with fatal errors. Not remotely compliant.

bun build --experimental-css ./style.css

No config needed to make it compliant.

postcssBundler()

Some config is needed to make it compliant.

postcssImport({
	skipDuplicates: false /* skipping duplicates is not how CSS works */,
})

• npm ci
• npm run install:with-firefox
• npm run test

• npm ci
• npm run serve <name of a test>

Sub string matches are fine,
npm run serve at-layer will serve the first test that contains at-layer.

Any test contributions are welcome!

You can open an issue and describe the case you want to test, or you can open a PR with a new test.

I don't care about technical purity, formatting, duplicates, ...
Anything that increases test coverage is very much appreciated.