Refactor: How should the 1,330-line bundler-filesystem.service.ts be d...

Documentation for Sessions

♻️ Refactor: How should the 1,330-line bundler-filesystem.service.ts be d...

Date: 2026-03-27
Time: 12:49:02 UTC
Session: gspace1-271.2
Agent: angular
Confidence: 95%
Status: ✅ Documented

📋 Decision Context

Question:

How should the 1,330-line bundler-filesystem.service.ts be decomposed to follow the Global Engineering Standard?

Task: S271: Decompose bundler-filesystem god-class following Global Engineering Standard

🎯 Decision Made

Chosen:

Extract 3 pure-function modules (P0+P1): enrichment/vfs-path-utils.ts (42 lines, shared path utilities), enrichment/scss-flattener.ts (188 lines, recursive descent SCSS parser), enrichment/source-transforms.ts (178 lines, 4 independent regex source transforms). Service drops from 1,330 to 923 lines. Remaining methods stay as service methods because they need DI context (sdkConfig, studioTaggingLoader, SDK_STUBS).

Options Considered:

  1. Extract 3 pure-function modules first (chosen — safest, highest impact)
  2. Extract all 6 concerns at once (risky, too many changes in one commit)
  3. Leave as-is and add tests instead (doesn't fix the structural problem)
  4. Rewrite as a pipeline of composable transform functions (ideal but requires changing the service API)

💭 Reasoning

Root cause: bundler-filesystem.service.ts grew organically across 15+ sessions (S224-S271) as each session added one more enrichment step to the pipeline. The enrichFileMap() god-method orchestrated 14 private methods spanning 6 distinct concerns: SCSS compilation, app shell synthesis, resource inlining, import repair, stub generation, and source transforms. The file violated every principle in the Global Engineering Standard: mixed responsibilities, methods that could be pure functions trapped as private methods on a service class, and no clear boundary between concerns. The extraction strategy targeted the 3 concerns with ZERO Angular DI dependencies first (path utils, SCSS parser, source transforms) because they could be extracted as pure function modules without changing any service wiring. The remaining concerns (app shell synthesis, import repair, stub generation) were left for a follow-up because they reference the CompilationStrategy injection token or SDK_STUBS config. The key risk was the SCSS parser's internal recursion chain (7 methods calling each other) — this was kept in a single module file to preserve the call graph. The source-transforms extraction was highest priority because it contained the trailing-comma bug that caused production SWC failures.

📁 Files Involved

🔗 Related

Auto-generated by MCP Smart Consolidation