@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.