updates primevue deps in package.json re: #12418

[chrabyrd]

Types of changes

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Description of Change

This change updates PrimeVue to the latest version, replaces the deprecated @primevue/themes package with the current primeuix/themes, and updates application-level pathing to support these changes.

Issues Solved

Closes #12418

Checklist

• I targeted one of these branches:
  • dev/8.1.x (under development): features, bugfixes not covered below
  • dev/8.0.x (main support): regressions, crashing bugs, security issues, major bugs in new features
  • dev/7.6.x (extended support): major security issues, data loss issues
• I added a changelog in arches/releases
• I submitted a PR to arches-docs (if appropriate)
• Unit tests pass locally with my changes
• I added tests that prove my fix is effective or that my feature works
• My test fails on the target branch

Accessibility Checklist

Developer Guide

Topic	Changed	Retested
Color contrast
Form fields
Headings
Links
Keyboard
Responsive Design
HTML validation
Screen reader

Ticket Background

• Sponsored by: Farallon
• Found by: @chrabyrd
• Tested by: @
• Designed by: @chrabyrd

Further comments

There is some debate about whether this belongs in dev/7.6.x, and I can argue that it does.

PrimeVue v4 moved themes to @primeuix/themes. Official docs show the correct import as import Aura from @primeuix/themes/aura. Leaving Arches 7.6.x on the old @primevue/themes path creates a divergence from upstream guidance. Some downstream apps pin dev/7.6.x but keep front-end deps current. If their dependency graph doesn't pull @primevue/themes, or if the application depends on other Arches applications that depend on later versions of PrimeVue themes, the Arches import could resolve to a module not found, or load an unstyled UI.

Although not a data-loss or security issue, this is a compatibility regression caused by an upstream deprecation that can render UIs unusable. Treating it as a stability fix is consistent with the spirit of extended support.

[chiatt]

Unfortunately this change doesn't qualify to be merged into the LTS because it does not address a data loss bug or a security issue. The purpose of this rule is to prevent the upgrade of dependencies for the sake of new functionality at the risk of introducing new bugs that might destabilize existing Arches implementations.

In fact, we have considered exact-pinning all of our front-end dependencies because of the possibility that even a dependency patch release could introduce problems: #11043

Merging this change would allow application developers to use a more recent version of primevue while keeping their applications compatible with Arches 7.6. That probably would be a benefit to 7.6 users that want to run those applications alongside their 7.6 instance. However, we could also ask those users to upgrade to v8, or if they need to be on an LTS, wait for Arches 8.2.0 LTS.

That could be very inconvenient for some users, so the benefits of this PR could outweigh the potential risks. However, the technical committee would need to make that assessment and decide whether or not this PR merits an exception to our policy.

[bferguso]

IMO I'd agree that the benefit would outweigh the risks.

I get the sense that Vue isn't heavily used in conjunction with 7.6 so the downside of continuing to direct users to the deprecated @primevue/themes library until 7.6.x is retired in 2027 (thereby making a transition to 8 more difficult) outweighs the potential side effects of any users that have already aligned themselves with the deprecated @primevue/themes library currently included in Arches Core 7.6.x.

I'd also suggest that the pattern for Vue integration with Arches, as well as how Apps interact with Arches Core is still being developed so perhaps modifying that part of the LTS release might be acceptable unless there are others have strong reasons to the contrary. I also think that not making the change now would likely stagnate/complicate the development of ancillary apps (component lab and modular reports, controlled lists, etc) until that LTS version is retired.

For our projects we've already had to implement a workaround to be able to use the @primeuix/themes library so we're not directly affected. What we're doing works, but it's not ideal as a long-term strategy.

If the PR is merged into 7.6.x, I'd suggest that additional communication efforts are made so that upgrading doesn't inadvertently break existing projects that are using the deprecated themes library.

[aj-he]

I think that LTS should have a policy for looking at dependencies that are deprecated or is EOL. We should also consider the impact of changes to licensing.

My immediate thoughts are that Elasticsearch 8 will likely hit this point soon and anyone using Elastic Cloud or other managed service will have limited time to move. It this is only put into Arches v8, then there could be a significant amount of work that can't be absorbed by the implementer. If 7.6 is LTS until 2027 then we need to be able to adjust the dependencies.

[apeters]

My review of the code concludes that this does indeed fix the issue with the primevue/themes being deprecated and causing issues with v7.6 installs of Arches.

The larger issue of whether this "should" be done has been discussed elsewhere in this ticket.

[chiatt]

Given the positive feedback on this PR and the significant benefit of moving forward with this change, I think we should go ahead and merge this in. When we announce the next release on the forum we can make special note of the change per @bferguso's suggestion regarding communication.