Add first-class SSR/server bundle config helper to reduce fragile rule mutation

[justin808]

Summary

Shakapacker’s generated base config is flexible, but for SSR server bundles we currently need fragile manual rule mutation in app code:

• strip CSS extraction/style loaders
• set css-loader to exportOnlyLocals
• disable asset emission for file/url loader rules
• force single chunk and node-target output behavior

This pattern is common enough that a first-class helper/API would reduce breakage across loader/plugin updates.

Why This Matters

In a React on Rails Pro + RSC demo, the server config has to iterate through module.rules and mutate internals by loader-name matching. That is brittle when dependencies or defaults evolve.

Suggested Improvement

Provide a supported server/SSR helper mode, for example:

• generateWebpackConfig({ target: 'node', ssr: true }), or
• a utility like applySsrServerBundleDefaults(config).

Expected behavior for the helper:

1. preserve CSS module class-name mapping for SSR (exportOnlyLocals behavior)
2. avoid emitting static assets from SSR bundle
3. avoid client-only plugins in server bundle
4. keep output/private-path conventions compatible with current Shakapacker config

Acceptance Criteria

• Apps can create SSR bundle configs without manually mutating module.rules internals.
• Helper behavior is covered by tests and documented for both webpack and rspack paths (where supported).

Duplicate Check

I searched for existing SSR helper/API issues and did not find one matching this request.

Related

• Version/DX tracking issue: Tracking: Improve gem/npm version drift DX and verification tooling #933

[justin808]

I evaluated this against current main and did not create a code PR from this lane. PR #1189 only documents the current multi-target watch workflow for #938.

Current main already shows and documents the SSR server-bundle pattern: strip CSS extraction/style loaders, preserve CSS module options while adding exportOnlyLocals, remove client/manifest plugins, and force server-bundle output/chunk behavior. Turning that into applySsrServerBundleDefaults or generateWebpackConfig({ ssr: true }) would be a new public API spanning webpack and Rspack parity, loader/plugin identity, asset emission, output/private-path behavior, and React on Rails expectations.

Given this issue is p3/defer with no current reproduction or customer evidence, I recommend keeping it deferred/product-decision until maintainers choose the supported API shape and parity contract.