@chenjiahan Hi! I didn't expect this to merge so quickly, as I'm unsure if this configuration scheme is the best we can get. Also, since we can't change the "test" property for the rule itself, do you have any ideas on how we can do this properly?

CRA (outdated, but whatever) uses source-map-loader for .css files too, I am not sure that this does something since the behavior of source map chain for CSS in both webpack/rspack/rsbuild...

@zalishchuk At first glance, this API design feels a bit verbose to me, though I haven’t come up with a simpler alternative.

Adding a test option sounds reasonable, and I can see it being useful in some scenarios. Would you like to submit a PR?

In the long term, I think we should support CSS source maps. But they don’t work well in some scenarios right now, for example web-infra-dev/rspack#10274 and users probably don’t rely on CSS source maps heavily. So it might make sense to revisit this and add support later.

@chenjiahan Sorry for the late reply. Yes, I will think about the best way to configure all these properties.

Hi @chenjiahan, wanted to ask your opinion on the sourceMap.extract API shape.

After giving it some more thought, I wonder if extract.js and the future extract.css might be an unnecessary layer of API nesting, since at their core, they are simply extract rules with different default test regexes.

• Keep supporting the current extract.js shape for backward compatibility.
• Mark extract.js as deprecated in docs/types.
• Recommend the flat object shape going forward.
• Keep extract: true as the current default JS behavior for compatibility.
• Still provide an easy way to enable/disable JS and CSS extraction separately. If the flat object defaults to JS only, users should not have to write a regex just to enable CSS extraction.

Maybe that means adding a simple preset field, similar to other Rsbuild options that use type:

sourceMap: {
  extract: {
    /** 'js' | 'css' | 'all' */
    type: 'all',
    include: [/node_modules[\\/]some-package[\\/]/],
  },
}

For more flexibility, users could still use tools.rspack and add a custom extractSourceMap rule themselves. Another option is to expose test directly in sourceMap.extract, but maybe that makes the Rsbuild API too close to Rspack for the common case.

Compared with the current schema:

type CurrentSourceMapExtract =
  | boolean
  | {
      js?:
        | boolean
        | {
            include?: Rspack.RuleSetCondition[];
            exclude?: Rspack.RuleSetCondition[];
          };
      /** future */
      // css?: boolean | {
      //   include?: Rspack.RuleSetCondition[];
      //   exclude?: Rspack.RuleSetCondition[];
      // };
    };

• Current: extract.js is a target namespace, but today there is only one real target.
• Current: future extract.css would duplicate the same include / exclude shape with a different built-in matcher.
• Proposed: extract directly describes one extraction rule, and type chooses the built-in matcher preset.
• Proposed: advanced matching can still be handled by test or by tools.rspack.

Example config with the proposed schema:

import { defineConfig } from '@rsbuild/core';

export default defineConfig({
  output: {
    sourceMap: {
      js: 'source-map',
      css: true,
      extract: {
        type: 'all',
        include: [/node_modules[\\/]some-package[\\/]/],
        // test: /\.js$/, // optional override of the built-in matcher
      },
    },
  },
});

The final shape could be something like:

type SourceMapExtractTarget = {
  /**
   * Specifies which built-in source map extraction rules should be enabled.
   * @default 'js'
   */
  type?: 'js' | 'css' | 'all';
  /** Optional escape hatch to override the built-in matcher. */
  test?: Rspack.RuleSetCondition;
  /** Include matched files whose existing source maps should be extracted. */
  include?: Rspack.RuleSetCondition[];
  /** Exclude matched files whose existing source maps should not be extracted. */
  exclude?: Rspack.RuleSetCondition[];
};

type DeprecatedSourceMapExtractTarget = {
  /** @deprecated Use `sourceMap.extract.type` instead. */
  js?: boolean | SourceMapExtractTarget;
  /** @deprecated Use `sourceMap.extract.type` instead. */
  css?: boolean | SourceMapExtractTarget;
};

type SourceMapExtract =
  | boolean
  | SourceMapExtractTarget
  | DeprecatedSourceMapExtractTarget;

Do you think this direction makes sense for Rsbuild, or would you prefer to keep extract.js as the main API in case we want target-specific defaults, like CSS, later?

Thanks for the proposal! I agree that the new API design looks cleaner and more elegant, and the points above are largely in line with my thoughts.

My guess is that extract.js hasn't been widely used yet, so deprecating it early and introducing a better API would be a good direction.

PRs are very welcome if you have time.