Duplicate Code: repeated ts-morph Project Node16 configuration in build-cli

🔍 Duplicate Code Detected: ts-morph Node16 Project configuration

Analysis of commit 92bb9570be8d1ff42628f2e025467a8462857e29

Assignee: @copilot

Summary

Multiple build-cli utilities create a ts-morph Project with the same baseline Node16 compiler settings (skipAddingFilesFromTsConfig: true + module: ModuleKind.Node16), with small variations (e.g., adding jsx / customConditions). This is a maintenance hazard because any future tweak (e.g., module resolution or ts-morph workarounds) must be kept in sync across several call sites.

Duplication Details

Pattern: Node16 ts-morph Project initialization

• Severity: Medium

• Occurrences: 3 (non-test)

• Locations:

  • build-tools/packages/build-cli/src/library/commands/generateEntrypoints.ts (lines ~543-556)
  • build-tools/packages/build-cli/src/commands/modify/fluid-imports.ts (lines ~627-632)
  • build-tools/packages/build-cli/src/commands/generate/typetests.ts (lines ~565-570)

• Code Sample:

const project = new Project({
	skipAddingFilesFromTsConfig: true,
	compilerOptions: {
		module: ModuleKind.Node16,
		// sometimes also:
		// jsx: 2 /* JSXEmit.React */,
		// customConditions,
	},
});

Impact Analysis

• Maintainability: Changes to compiler options / ts-morph workarounds must be repeated in multiple files, risking drift.
• Bug Risk: Inconsistent Project configuration can yield different symbol resolution/export detection behavior between commands.
• Code Bloat: Small but repeated boilerplate across core build tooling.

Refactoring Recommendations

1. Extract a shared helper

   • Create a utility like createNode16Project(options) in a shared build-cli library module (e.g., build-tools/packages/build-cli/src/library/tsMorphProject.ts).
   • Provide optional parameters for customConditions, jsx, and other per-command overrides.
   • Benefits: single source of truth; easier to evolve ts-morph setup.

2. Centralize constants for baseline compilerOptions

   • Export a node16CompilerOptions constant and spread it into call sites.
   • Benefits: minimal refactor; keeps call-site flexibility.

Implementation Checklist

• Identify all new Project({ skipAddingFilesFromTsConfig: true, compilerOptions: { module: ModuleKind.Node16 } }) call sites in build-cli
• Add shared helper/constant in build-cli library
• Update call sites (including ones not touched in this commit)
• Run build-cli unit tests + any relevant flub command smoke checks

Analysis Metadata

• Analyzed Files: 10 (recent non-test .ts/.cjs/.mjs files from last 5 commits)
• Detection Method: Serena symbol overview + repo-wide pattern search
• Commit: 92bb9570be8d1ff42628f2e025467a8462857e29
• Analysis Date: 2026-03-16T08:12:13.656Z

AI generated by Duplicate Code Detector

To add this workflow in your repository, run gh aw add github/gh-aw/.github/workflows/duplicate-code-detector.md@94662b1dee8ce96c876ba9f33b3ab8be32de82a4. See usage guide.

Start by inspecting the three listed Project initialization sites: generateEntrypoints.ts, fluid-imports.ts, and typetests.ts, then search build-cli for additional Node16 configurations. Decide whether a shared helper or compiler-options constant fits the per-command overrides, update the call sites, and run build-cli unit tests plus relevant flub smoke checks.