Customizing CSS Modules requires reaching into the generated bundler config and rewriting css-loader options by walking rules. This is repetitive across projects and harder to maintain.
I’d like @gravity-ui/app-builder to expose property in ServiceConfig to configure CSS Modules, e.g. toggling default export vs. named export and setting localIdentName.
Why this matters
Rspack’s default for CSS Modules is named export only (see docs). This creates a compatibility issue, as many existing codebases and popular UI component libraries rely on or exclusively support default imports for their styles:
import styles from './*.module.css';
Current workaround
Right now we have to mutate the internal rules to find css-loader and patch its options:
// app-builder.config.ts
export default function(): ServiceConfig {
return {
client: {
bundler: 'rspack',
rspack: (config) => {
for (const rule of config.module.rules) {
if (rule && Array.isArray(rule.oneOf)) {
for (const oneOfRule of rule.oneOf) {
if (oneOfRule && Array.isArray(oneOfRule.use)) {
oneOfRule.use = oneOfRule.use.map((loader) => {
if (
typeof loader === 'object' &&
loader.loader?.includes('css-loader')
) {
return {
...loader,
options: {
...loader.options,
modules: {
...loader.options?.modules,
namedExport: false,
localIdentName: '[folder]__[local]--[hash:base64:5]',
},
},
};
}
return loader;
});
}
}
}
}
return config;
},
},
};
}
This works, but it’s fragile and duplicates logic across services.
Proposal
Add a css property to ServiceConfig.client to provide a declarative way to configure CSS Modules:
export default function(): ServiceConfig {
return {
client: {
bundler: 'rspack',
css: {
modules: {
namedExport: false,
localIdentName: '[folder]__[local]--[hash:base64:5]',
},
},
// another existing options
// transformCssWithLightningCss: true,
},
};
}
Customizing CSS Modules requires reaching into the generated bundler config and rewriting
css-loaderoptions by walkingrules. This is repetitive across projects and harder to maintain.I’d like @gravity-ui/app-builder to expose property in
ServiceConfigto configure CSS Modules, e.g. toggling default export vs. named export and settinglocalIdentName.Why this matters
Rspack’s default for CSS Modules is named export only (see docs). This creates a compatibility issue, as many existing codebases and popular UI component libraries rely on or exclusively support default imports for their styles:
Current workaround
Right now we have to mutate the internal rules to find css-loader and patch its options:
This works, but it’s fragile and duplicates logic across services.
Proposal
Add a css property to
ServiceConfig.clientto provide a declarative way to configure CSS Modules: