test(react-icons-atomic-webpack-loader): verify fixtures against rspack

[Martin Hochel (Hotell)]

Why

@fluentui/react-icons-atomic-webpack-loader was only ever exercised against webpack. Since #1219
established rspack support for the font subsetting plugin, that claim should be tested here too
rather than assumed.

Change

The fixture entries and their assertions move into a shared test/make-configs.js, and
test/run.js (--bundler webpack|rspack|all) drives both bundlers over the same 17 entries.
test/webpack.config.js becomes a thin wrapper, so the existing webpack behaviour is unchanged.

The rspack config deliberately keeps the same ts-loader setup as webpack rather than switching
to builtin:swc-loader, so that any difference in emitted output comes from the bundler rather than
from a different TypeScript toolchain.

Result: no per-bundler overrides were needed

All 17 entries pass under rspack unmodified, including the three things I expected to be risky:

Expected risk	Outcome
ts-loader under rspack (.jsx / .tsx fixtures)	works
experiments.outputModule + library: { type: 'module' }	works; every mustInclude/mustExclude string assertion holds
Emitted-warning assertions (dynamic-barrel-imports)	works after the fix below

make-configs.js still supports overrides.<bundler> so a future divergence has somewhere to go,
but nothing uses it today.

One real bug found

The assertion plugin read warnings as:

compilation.warnings.map((w) => (w instanceof Error ? w.message : String(w)))

rspack surfaces RspackError objects rather than Error instances, so this would have fallen into
the String(w) branch and produced [object Object] — the mustWarn assertions would have failed
confusingly rather than reporting the real warning. Now reads message directly, which is correct
for both bundlers.

Type leak fixed

lib/index.d.ts carried import type { LoaderContext } from 'webpack'. With both bundlers now
declared as optional peers, an rspack-only consumer would hit Cannot find module 'webpack'
while type-checking — the same defect fixed in #1219 for the font plugin.

Replaced with a hand-maintained AtomicLoaderContext covering the four members the loader actually
uses (resourcePath, getOptions, callback, emitWarning), plus
test/types.conformance.ts asserting that both bundlers' real LoaderContext still satisfies
it. Verified the check is not vacuous: adding a member no bundler has fails compilation for both.

Peer range

@rspack/core is declared as >=2.1.0, matching the font plugin. The loader itself only touches the
loader context, which has been stable since rspack 1.x, so a lower floor would technically work — but
2.1.0 is the only version this suite exercises, and advertising untested versions is what produced
the incorrect range caught in review on #1219.

Verification

• nx run …:test — vitest + type conformance + webpack 17/17 + rspack 17/17
• Negative test: a deliberately unsatisfiable mustInclude fails under rspack with
  [rspack/svg-imports] Expected output to contain "THIS-SHOULD-NOT-EXIST", proving the rspack path
  actually evaluates assertions rather than passing vacuously
• Conformance negative test: adding a bogus required member fails for both bundlers
• Warnings confirmed genuinely captured under both bundlers (2 each on dynamic-barrel-imports)
• nx run …:lint, yarn deps:check, and yarn install --immutable all pass

[github-actions]

📋 PR Validation Summary

Check the Build react library job summary for detailed reports:

• 📦 Bundle Size — size comparison against the base branch
• 📖 Docsite Preview — build artifact with local preview instructions

To view: click the link above → select the Build react library job → open the Summary tab.