Skip to content

CI_COMPONENTS_DTS_FIX.md

Latest commit

 

History

History
50 lines (34 loc) · 3.56 KB

CI_COMPONENTS_DTS_FIX.md

File metadata and controls

50 lines (34 loc) · 3.56 KB
Raw

CI: "Check for changes to source during build" and components.d.ts

What failed

The PR Check workflow step "Check for changes to source during build" (in .github/workflows/cicd_comp_build-phase.yml) runs git status --porcelain after the Maven build. If any file in the working tree is modified or added, the step fails.

The file that was causing the failure: core-web/libs/dotcms-webcomponents/src/components.d.ts.

Why it started failing (what changed lately)

  1. The check step is not new
    It was added in July 2024 (commit c6c0834c, PR #29137) to protect against the initial build modifying source files that are not committed.

  2. What changed recently

    • main has components.d.ts committed with imports using the package path:
      from "@dotcms/dotcms-models".
    • After the PrimeNG v21 / Angular 21 migration (e.g. #34388, Jan 2026), the Stencil compiler in this repo generates components.d.ts with relative paths:
      from "../../dotcms-models/src/index".
    • So when CI runs the full Maven build, Stencil regenerates components.d.ts in place. The generated content (path style, and possibly formatting/order) no longer matches the committed version, so git status sees a modification and the step fails.
    • On main, the committed file either matched what Stencil produced at that time, or the build path/tsconfig was such that the file was not regenerated differently. The branch’s path resolution / build setup makes the generated file differ from the one in git.

  3. Summary
    The step did not change; the build output for components.d.ts did (path resolution / Angular 21 / Nx context). So the same protection step that has been there since July 2024 now fails on this branch because one generated file is always “modified” after the build.

Approach taken: ignore and stop tracking components.d.ts

  • .gitignore
    Added:
    /core-web/libs/dotcms-webcomponents/src/components.d.ts

  • Stop tracking
    The file was removed from the index with git rm --cached so it is no longer tracked. It is still generated on disk by Stencil during the build.

Why this is acceptable

  • The published types for the package come from the build output, not from src/: in core-web/libs/dotcms-webcomponents/package.json, "types" points to
    "../../dist/libs/dotcms-webcomponents/dist/types/components.d.ts".
    So consumers and the rest of the monorepo use the built types.
  • The copy in src/ is generated by Stencil for the compiler’s own use. Not tracking it avoids the CI failure when the generated content differs from a previously committed version.
  • Stencil’s docs suggest committing components.d.ts for type safety and build order; in this repo, types are provided via dist and path aliases in tsconfig.base.json, so ignoring the generated file in src/ is a reasonable trade-off to keep CI green without changing the public contract of the library.

Alternative considered

  • Making the generated file deterministic (e.g. so Stencil always emits @dotcms/dotcms-models instead of relative paths) would require Stencil/tsconfig changes and may not be fully under our control. The .gitignore approach is the one applied.

References

  • Workflow: .github/workflows/cicd_comp_build-phase.yml (step “Check for changes to source during build”).
  • Failing run (example): https://github.com/dotCMS/core/actions/runs/21871377611
  • Stencil generated file: core-web/libs/dotcms-webcomponents/src/components.d.ts (autogenerated, now ignored and untracked).