Any plans to remove css-loader now that it's archived and deprecated?

[spdaley]

Looks like https://github.com/webpack/css-loader was archived a couple of months back.
Their documentation has been updated to recommend using the native-css built in to webpack 5.

It looks like @storybook/builder-webpack5 brings in css-loader as a direct dependency.

Do we know if there are any plans to remove css-loader as a direct dependency given that knowledge?

Mostly asking because some of the css-loader modules have dependencies with CVEs associated with them now and the modules are using older versions of those dependencies that will probably not be patched. So we started migrating over to native webpack per the migration guide but we still get css-loader through builder-webpack5.

[dgesteves]

As far as I can see, nothing is tracked yet. @storybook/builder-webpack5 still depends on css-loader@^7.1.2 (and style-loader@^4.0.0) in both latest (10.6.1) and next (11.0.0-alpha.4). I found no issue or PR about dropping it; the only recent css-loader work is #35485, which aligned on v7 and pinned the CSS Modules export defaults.

It's used in code/builders/builder-webpack5/src/preview/base-webpack.config.ts. That file adds an implicit .css rule (style-loader + css-loader with modules.auto, namedExport: false, exportLocalsConvention: 'as-is') unless @storybook/addon-postcss is in your presets. There's already a // TODO: Decide if we want to keep style-loader & css-loader in core above it. @storybook/nextjs also uses css-loader separately, in frameworks/nextjs/src/css/webpack.ts.

Your options today:

1. Get it out of the tree: move to the Vite builder (@storybook/react-vite etc.), which doesn't pull css-loader. Without an upstream change, that's the only thing that makes scanners stop reporting it.
2. Keep webpack but stop using it: drop Storybook's rule in webpackFinal and let webpack's native CSS handle it with the same semantics. The package stays installed because it's a hard dependency of the builder, so this helps your migration but not the audit report.

// .storybook/main.ts
import type { StorybookConfig } from '@storybook/react-webpack5'

const usesCssLoader = (rule: any) =>
  Array.isArray(rule?.use) &&
  rule.use.some((u: any) => String(typeof u === 'string' ? u : u?.loader).includes('css-loader'))

const config: StorybookConfig = {
  // ...
  webpackFinal: async (config) => {
    config.module ??= {}
    config.module.rules = (config.module.rules ?? []).filter((r) => !usesCssLoader(r))
    config.module.parser = { ...config.module.parser, 'css/auto': { exportType: 'style', namedExports: false } }
    config.module.generator = { ...config.module.generator, 'css/auto': { exportsConvention: 'as-is' } }
    config.experiments = { ...config.experiments, css: true }
    return config
  },
}
export default config

exportType: 'style' replaces style-loader, and namedExports: false plus exportsConvention: 'as-is' keep import styles from './x.module.css' working as it does now. I checked this config in a plain webpack 5.111 build, not inside a full Storybook setup, so try it on a branch first.

3. For the CVEs themselves: css-loader 7.1.5 uses caret ranges (postcss ^8.4.40, postcss-modules-*, icss-utils ^5.1.0, semver ^7.6.3). Fixes inside those ranges arrive with a lockfile refresh; anything outside them needs overrides (npm, or pnpm-workspace.yaml for pnpm) or resolutions (Yarn).

If you want this fixed upstream, a feature request pointing at that TODO is the way to go. The change is small: when native CSS is available, emit type: 'css/auto' with the parser/generator options above instead of the loader chain, then drop both dependencies in the next major.

[spdaley]

Thanks. For now, we've just mitigated it by silencing it in our local environment. For devDependencies I'm generally ok with doing that but we do keep track of everything we've silenced and try to see where things go with them so we can get our excludes cleaned up eventually. I was originally going to start on the css-loader side and submit issues for its dependent modules until I saw they've archived it. That was my main motivation for asking about it here as it seemed like their deprecation was fairly new and I wasn't sure if that was known around here or not.

[dgesteves]

Makes sense. Silencing the warning for a devDependency while keeping it on your radar seems like a reasonable approach for now.

I had a look around, and I couldn't find an existing issue or PR tracking this on the Storybook side. Meanwhile, @storybook/builder-webpack5@11.0.0-alpha.4 still depends on css-loader.

It might be worth opening a feature request referencing the existing TODO in base-webpack.config.ts. That would give you something concrete to reference in your exclusion list and give the team a place to discuss whether removing the dependency makes sense.

If this helped resolve your question, feel free to mark it as the answer. It'll make it easier for others running into the same scanner warning to find the explanation.

[spdaley]

So it seems like opening a feature request is just opening another discussion? Didn't realize that until after I clicked though. Well we'll see what happens there.

[dgesteves]

Yes, Storybook keeps feature requests in the Ideas category of Discussions, and the team turns them into issues when they pick one up. Thanks for opening #36713. An upvote there from anyone else hitting the CVE warnings is the clearest signal for them.