Added pre-commit config for formatting the UI code

[ChrisSmithCGI]

Resolves #4955

What is being addressed

Added a prettier pre-commit hook for formatting the frontend codebase

How is this addressed

• Describe the changes made, and if appropriate, why they are addressed this way
• Note any pending work (with links to the issues that will address them)
• Update documentation
• Update CHANGELOG.md if needed
• Increment template version if needed, for guidelines see Authoring templates - versioning

[Copilot]

Pull request overview

Adds automated UI code formatting by wiring Prettier into the repository’s pre-commit workflow, and aligns UI formatting defaults/versioning with that change.

Changes:

• Add a Prettier pre-commit hook scoped to the UI app directory.
• Update the UI Prettier configuration (trailing commas + print width).
• Bump the UI package version and record the enhancement in the changelog.

Reviewed changes

Copilot reviewed 4 out of 5 changed files in this pull request and generated 3 comments.

File	Description
ui/app/package.json	Bumps UI package version to reflect the formatting tooling change.
ui/app/.prettierrc	Extends Prettier formatting rules used for UI code.
CHANGELOG.md	Notes the new pre-commit-based UI formatting support under Enhancements.
.pre-commit-config.yaml	Adds a Prettier hook to run on ui/app files during pre-commit.

Files not reviewed (1)

• ui/app/package-lock.json: Generated file

[github-actions]

Unit Test Results

241 tests   241 ✅  21s ⏱️
 27 suites    0 💤
  1 files      0 ❌

Results for commit 54b1eb4.

♻️ This comment has been updated with latest results.

[marrobi]

Easier to review! LGTM.

[JC-wk]

LGTM
Interested to hear opinions on printWidth (120 was my suggestion)
can be tested with
pre-commit run --all-files
and comparing the changes

[ChrisSmithCGI]

LGTM Interested to hear opinions on printWidth (120 was my suggestion) can be tested with pre-commit run --all-files and comparing the changes

From memory, or at least this was what was explained to me when I was new, 80 characters at size 14 font printed without wrapping on A4 back when people used to print project reports for architectural reviews.

.. or something like that. My personal .dotfiles usually specify 120 as the soft wrap and 160 as the hard wrap. Since most of us don't print code any more, I think it mostly falls to team preference - with the only real physical driver potentially being how much code can be fit on a half screen without wrapping. If there is no strong opinion, then someone needs to make a decision (/ht @JC-wk) or the defaults should be used. There are couple of prettier plugins that adjust that rule to accommodate framework nuances / eccentricities.