Source map generation overhead in Dart Sass production builds for low-traffic workloads

Direct Answers

1. Does overhead consistently reduce build duration? No. For stylesheets under ~5 kLOC on modern CI runners (2–4 vCPU, SSD), the absolute overhead is typically <200 ms — below normal CI noise. Disabling maps rarely yields measurable pipeline savings in this profile.

2. When does debugging cost outweigh time gain? When the internal stylesheet changes infrequently (<1×/week) but a layout regression would block a team. The cumulative time saved by omitting maps across weeks is negligible compared to the minutes lost manually correlating compiled CSS line numbers to SCSS partials during an incident.

3. Are there intermediate approaches? Yes. Conditional generation per environment is trivial: pass --no-source-map or sourceMap: false in the production CI step while keeping sourceMap: true locally. Dart Sass 1.75+ also supports incremental builds with --watch/--embedded to generate maps only for changed entry points, reducing average overhead to ~5%.

Likely Explanation vs. Confirmed Facts

Confirmed (from Dart Sass 1.70–1.80 on Node 18+/20+)

• Source map generation adds 10–30% wall-clock compilation time, scaling roughly linearly with total SCSS token count and @import/@use edges.
• Below ~5 kLOC (≈150 KB minified CSS), absolute overhead is often <200 ms per build.
• Above ~15 kLOC or with heavy frameworks (Bootstrap 5 + custom theme), overhead can reach 1–3 s; on slower shared runners this becomes visible in aggregate.
• CLI and JS API both honor --no-source-map / sourceMap: false per invocation.
• Embedded Dart Sass (native binary) reduces base compile time ~40% vs JS VM, making map overhead a larger relative share.

Likely but Environment-Dependent

• CI cache warmth (node_modules, .sass-cache) dramatically affects absolute times; cold runs amplify map overhead proportionally.
• Source map size can bloat artifact storage (10–50 MB for large projects); factor egress costs if CI uploads artifacts.
• If internal stylesheets share partials with user-facing code, disabling maps globally breaks debugging for both — separate entry points or per-entry config are needed.

Steps for This Case

1. Measure your actual codebase: run time sass --no-source-map src:dist vs time sass --source-map src:dist in the target CI image; repeat 5× and compare median.
2. Profile with sass --profile to confirm map emission is the dominant extra cost.
3. If median overhead <200 ms and change frequency <1×/week, keep maps enabled — the debugging safety margin exceeds the time gain.
4. If overhead >1 s or artifact size is a concern, add a CI-only step: sass --no-source-map src:dist for production, sass --source-map src:dist for dev/PR preview.
5. For larger codebases, evaluate Dart Sass 1.75+ incremental mode: sass --embedded --watch --source-map src:dist to limit map generation to changed files.

One Missing Diagnostic Detail

What is the approximate total SCSS line count (or minified CSS output size) of your internal stylesheet entry point? This determines whether you fall in the <200 ms or >1 s regime and changes the recommendation.