Duplicate Code: repeated useHashes/env-var boilerplate in fluid-build leaf tasks

Analysis of commit 0c9fe12e54e768e7eed3763b802e3ad031d88d47

Assignee: @copilot

Summary

Multiple LeafWithFileStatDoneFileTask subclasses in miscTasks.ts repeat the same multi-line JSDoc + useHashes getter pattern to enable content-hash based incremental detection via an env var. This is a 4x duplication that increases maintenance cost (any wording/behavior change must be kept in sync).

Duplication Details

Pattern: “Enable hashing via FLUID_BUILD_ENABLE_*_HASH” JSDoc + useHashes getter

• Severity: Medium

• Occurrences: 4

• Locations:

  • build-tools/packages/build-tools/src/fluidBuild/tasks/leaf/miscTasks.ts (lines 67–78) — CopyfilesTask
  • build-tools/packages/build-tools/src/fluidBuild/tasks/leaf/miscTasks.ts (lines 255–266) — TypeValidationTask
  • build-tools/packages/build-tools/src/fluidBuild/tasks/leaf/miscTasks.ts (lines 309–320) — GoodFence
  • build-tools/packages/build-tools/src/fluidBuild/tasks/leaf/miscTasks.ts (lines 351–362) — DepCruiseTask

• Code Sample (representative; varies only by env var name):

  /**
   * Use content hashes instead of file timestamps for incremental build detection.
   * ...
   * Set the FLUID_BUILD_ENABLE_(TASK)_HASH environment variable to "1" to enable hashing.
   * By default, timestamps are used.
   */
  protected override get useHashes(): boolean {
    return process.env.FLUID_BUILD_ENABLE_(TASK)_HASH === "1";
  }
  

Impact Analysis

• Maintainability: Any change to hashing-enable semantics (e.g., accepting "true"/"yes", renaming vars, clarifying docs) must be applied in 4 places.
• Bug Risk: Easy for one task to drift (typo’d env var name, diverging docs vs behavior).
• Code Bloat: ~40–50 lines of near-identical boilerplate in one file.

Refactoring Recommendations

1. Extract a shared helper for env-var based hashing enablement

   • Example: build-tools/packages/build-tools/src/fluidBuild/tasks/leaf/hashToggle.ts (or a shared utility near task base classes)
   • API idea:
     • isHashingEnabled(envVar: string): boolean or hashingEnabledFromEnv(envVar: string): boolean
     • Then each task’s getter becomes a one-liner calling the helper.
   • Estimated effort: Low (1–2 hours)
   • Benefits: Centralized behavior, easier to adjust accepted values / telemetry / validation.

2. Optional: reduce repeated doc blocks

   • Keep a short per-task note (env var name) and reference a shared doc (or base-class doc) for the rest.
   • Estimated effort: Low-Medium

Implementation Checklist

• Introduce helper function for hashing enablement
• Update each task to use helper
• Decide whether to keep or shorten per-task JSDoc
• Run build-tools tests / lint

Analysis Metadata

• Analyzed Files: 1 (targeted semantic + text search)
• Detection Method: Serena semantic code analysis + pattern search
• Commit: 0c9fe12e54e768e7eed3763b802e3ad031d88d47
• Analysis Date: 2026-03-21

Note: the checkout appears shallow (no diff base available), so this report focuses on significant duplication found in the relevant build tooling area rather than “newly introduced” code only.

Generated by Duplicate Code Detector · ◷

To install this agentic workflow, run

gh aw add github/gh-aw/.github/workflows/duplicate-code-detector.md@94662b1dee8ce96c876ba9f33b3ab8be32de82a4

Start in build-tools/packages/build-tools/src/fluidBuild/tasks/leaf/miscTasks.ts, reviewing the four useHashes getters in CopyfilesTask, TypeValidationTask, GoodFence, and DepCruiseTask. Then inspect nearby task base classes or utilities before deciding where the shared hashing helper belongs. Done means the repeated enablement behavior is centralized, the four tasks use it consistently, and build-tools tests and lint pass.