Integrate @ng-dynamic-forms in code base and upgrade ng-bootstrap version.

[FrancescoMolinaro]

References

Fixes #1272

Description

This PR brings the code from the @ng-dynamic-forms library directly into the DSpace codebase (under src/external-libraries). The upstream library is no longer maintained, and its outdated dependencies were blocking important framework upgrades (e.g., ng-bootstrap).

By decoupling from the external library, we can now upgrade those dependencies and continue improving the components and services originally provided by @ng-dynamic-forms. As part of this migration, the code has already been optimized for newer Angular versions, and all templates have been migrated to use Angular’s control flow syntax.

A notable improvement resulting from the upgrade is the resolution of the accessibility issue related to ngbTypehead. The previously reported aria-multiline violation detected by axe DevTools is no longer present.

Old version:

After upgrade:

The code is under ISC license so all the files will contain a copy of the license text specified in the repo: https://github.com/udos86/ng-dynamic-forms?tab=ISC-1-ov-file

Instructions for Reviewers

This PR does not introduce new features. All library components should behave and appear the same as before. The focus is strictly on migrating and updating the code.

List of changes in this PR:

Integrated the relevant portions of @ng-dynamic-forms (core and ui-ng-bootstrap) into the repository under src/external-libraries/ng-dynamic-forms/.

Updated tsconfig paths and imports across the application:

"@ng-dynamic-forms/core/": ["src/external-libraries/ng-dynamic-forms/core/"]
"@ng-dynamic-forms/ui-ng-bootstrap/": ["src/external-libraries/ng-dynamic-forms/ui-ng-bootstrap/"]

Upgraded ng-bootstrap to v15.1.2 and updated imports where needed (module → standalone).

Migrated all library templates to Angular's control flow syntax.

Applied ESLint fixes where possible within the migrated library code.

Test:

To verify the fix for the aria-multiline accessibility issue:

1. Use axe DevTools on any form containing:
   a dynamic-onebox component, or
   any component using the ngbTypehead directive.

2. In the current main branch, axe should report the aria-multiline violation.

3. When testing the same form with this PR, the violation should no longer appear.

Checklist

This checklist provides a reminder of what we are going to look for when reviewing your PR. You do not need to complete this checklist prior creating your PR (draft PRs are always welcome).
However, reviewers may request that you complete any actions in this list if you have not done so. If you are unsure about an item in the checklist, don't hesitate to ask. We're here to help!

• My PR is created against the main branch of code (unless it is a backport or is fixing an issue specific to an older branch).
• My PR is small in size (e.g. less than 1,000 lines of code, not including comments & specs/tests), or I have provided reasons as to why that's not possible.
• My PR passes ESLint validation using npm run lint
• My PR doesn't introduce circular dependencies (verified via npm run check-circ-deps)
• My PR includes TypeDoc comments for all new (or modified) public methods and classes. It also includes TypeDoc for large or complex private methods.
• My PR passes all specs/tests and includes new/updated specs or tests based on the Code Testing Guide.
• My PR aligns with Accessibility guidelines if it makes changes to the user interface.
• My PR uses i18n (internationalization) keys instead of hardcoded English text, to allow for translations.
• My PR includes details on how to test it. I've provided clear instructions to reviewers on how to successfully test this fix or feature.
• If my PR includes new libraries/dependencies (in package.json), I've made sure their licenses align with the DSpace BSD License based on the Licensing of Contributions documentation.
• If my PR includes new features or configurations, I've provided basic technical documentation in the PR itself.
• If my PR fixes an issue ticket, I've linked them together.

[artlowel]

I appreciate the work you put in this @FrancescoMolinaro, but I don't agree with the approach of this PR.

In our developer meetings around #2216, the consensus was that we needed to move away for @ng-dynamic-forms, the main question was if we'd do it with a different form lib, or just using angular's built in forms.

We've put that work on hold now for the CRIS merger, but that doesn't mean we'll stick with @ng-dynamic-forms. I plan to make it a priority as soon as the CRIS merger is out of the way.

Because of that, I’m hesitant about temporarily adding ~8,000 lines of code to fix an accessibility issue that's been open for over 4 years, only to remove it all again next year.

The fact that ng-bootstrap is outdated, also hasn’t been a big problem so far. We were able to upgrade to Bootstrap 5 and Angular 20 just fine.

But if you really want to upgrade it @ng-dynamic-forms right away, an approach I could agree with would be to apply the fixes to your fork of the library, I see you've already made a start in udos86/ng-dynamic-forms#1185. Then deploy your own version of the library on NPM, and make a tiny PR for dspace that updates the dependency to your version.

The added advantage to that approach is that other projects that depend on @ng-dynamic-forms can use your fork as well and will likely thank you for it.

[FrancescoMolinaro]

Hi @artlowel , thank you for the feedback. I agree with the proposed approach, and as you noted, my initial thought was also to upgrade the library within its own repository.

I raised this topic in the last meeting, and we aligned on proceeding in this direction. We will then create a temporary npm package that will be maintained until the migration away from this library is completed.

I’ll follow up with a new PR as soon as possible.
Thanks again for the review and the helpful input.