[Feature]: a `css` option so stylesheet imports resolve without a preprocessor plugin

[fi3ework]

What problem does this feature solve?

A test file that imports a component also pulls in that component's stylesheet, because components declare it as a bare side-effect import (import './styles.less'). The test never reads a computed style — it asserts on the class names the component produces — but Rspack still has to resolve that import at build time, so the run fails before a single test executes.

Minimal reproduction on Rstest 0.11.6 (four files, node environment, no plugins):

// package.json
{ "private": true, "type": "module" }
// + @rstest/core@0.11.6

// rstest.config.ts
import { defineConfig } from '@rstest/core';

export default defineConfig({
  testEnvironment: 'node',
  include: ['test/**/*.test.ts'],
});

// src/styles.less
@primary: #1677ff;

.button {
  color: @primary;
}

// src/button.ts
import './styles.less';

export function buttonClassName(): string {
  return 'button';
}

// test/button.test.ts
import { expect, test } from '@rstest/core';
import { buttonClassName } from '../src/button';

test('asserts on a class name, never reads a style', () => {
  expect(buttonClassName()).toBe('button');
});

npx rstest:

× Module parse failed:
╰─▶   × JavaScript parse error: Expression expected
       ╭─[1:0]
     1 │ @primary: #1677ff;
       · ─
     2 │
     3 │ .button {
       ╰────

help:
      You may need an appropriate loader to handle this file type.

Varying only the extension and the plugin list, on the same 0.11.6:

import	plugins	result
./styles.css	none	passes
./styles.less	none	Module parse failed
./styles.less	@rsbuild/plugin-less	passes

Plain CSS is already inert without any configuration. A preprocessor stylesheet is not: the only way to get the import to resolve is to install the matching plugin and its compiler (@rsbuild/plugin-less brings in less@4.8.1). That adds a Less/Sass toolchain to a test setup solely so a file nobody reads can be parsed, and it means the run compiles stylesheets whose output is discarded.

The error is also hard to place from the message alone — it points at line 1 of a stylesheet and reports a JavaScript parse error, so it reads like a broken source file rather than a missing capability.

Vitest covers this case with test.css, which defaults to processing nothing and replaces the module with an empty string. Under that default neither .css nor .less requires any preprocessor to be installed.

[fi3ework]

Some follow-up on where the asymmetry in that table actually comes from, since it turned out to be narrower than I assumed when filing.

The .less failure is not about Less syntax. A .less file containing nothing but valid plain CSS fails identically — the rule that would handle it simply does not exist.

What makes .css inert is Rsbuild's rsbuild:css plugin, not anything in Rstest. The rule is registered as test(CSS_REGEX) with CSS_REGEX = /\.css$/, and the main branch picks its loader from emitCss:

const emitCss = config.output.emitCss ?? target === 'web';
if (emitCss) { /* style-loader or mini-css-extract */ }
else mainRule.use(CHAIN_ID.USE.IGNORE_CSS).loader(join(dirname, 'ignoreCssLoader.mjs'));

Under the node target emitCss is false, so ignoreCssLoader is inserted, and its pitch short-circuits the whole chain for non-modules:

const pitch = function () {
  const { modules } = this.getOptions();
  if (!isCSSModules(modules, this)) return '';
};

That pitch is extension-agnostic. It also explains the third row of the table, which I had read wrong: installing @rsbuild/plugin-less does not make the stylesheet compile. The plugin clones the CSS rule's entire use chain before appending less-loader:

for (const id of Object.keys(cssBranchRule.uses.entries())) {
  const loader = cssBranchRule.uses.get(id);
  rule.use(id).loader(loader.get('loader')).options(clonedOptions);
}
rule.use(CHAIN_ID.USE.LESS).loader(lessLoaderPath).options(options);

So the cloned chain starts with ignore-css, the pitch returns '', and less-loader never runs under the node target. The plugin's only effect in a test build is that a rule matching /\.less$/ now exists at all. The Less compiler it drags in is dead weight for the entire run.

So the mechanism .css uses already applies to .less unchanged — nothing needs to be compiled, and no preprocessor is required. What is missing is rule registration: with no plugin installed, no rule tests /\.less$/, so Rspack falls through to the JavaScript parser and reports Expression expected at line 1.

Two things a fallback rule would have to handle:

1. Collision. If @rsbuild/plugin-less (or -sass, -stylus) is present, both rules would match and their loaders would stack. Registration would need to run late and skip any extension some existing rule already tests.
2. CSS Modules. The pitch deliberately lets .module.* through so SSR builds can export locals, but with no preprocessor there is nothing downstream to compile it. Under a css: false option this is exactly where Vitest's classNameStrategy behavior fits — return a proxy that echoes the requested key, so .module.less also stops needing a compiler. Without such an option it would at least need a message naming the missing plugin rather than another Module parse failed.

Versions used for the above: @rstest/core@0.11.5, @rsbuild/core@2.1.8, @rsbuild/plugin-less@1.6.4.