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.

[FrancescoMolinaro]

Hi @artlowel , i have updated the PR as we discussed by publishing the updated library.
The packages can be found here:

https://www.npmjs.com/package/@4science_ng-dynamic-forms/core
https://www.npmjs.com/package/@4science_ng-dynamic-forms/ui-ng-bootstrap

The import paths have been configured as the old ones in the tsconfig, so to avoid changes in the imports.
Accordingly to the scope of the PR I have then updated ng-bootstrap and ngx-mask, as it depended on the first one.

I would really appreciate if you could have another look to the PR.

[artlowel]

Thanks @FrancescoMolinaro.

It looks good to me this way. I was just wondering if the overrides for the angular versions in package.json are still necessary now

[artlowel]

Thanks @FrancescoMolinaro!

[tdonohue]

@FrancescoMolinaro : I gave this a test & review today. Overall it looks good and it works well. However, I've found it only partially fixes #1272.

There are two parts to #1272:

1. The aria-multiline attribute is invalid on combobox role (it currently appears for dc.subject field). (FIXED by this PR)
2. The <select> for the dc.identifier field doesn't have a <label> or an aria-label attribute. (NOT FIXED by this PR)
   • In fact you can see this error still in your screenshot above where axe DevTools still returns a "Select element must have an accessible name" error.

I suspect the additional fix here actually needs to be applied in the new @4science_ng-dynamic-forms library. But, I'm assuming that will require a new version which may need updating here.

Beyond that, this approach looks good and the code looks good.

[tdonohue]

NOTE: I also checked the versions of ng-dynamic-forms and ng-bootstrap on all maintenance branches. It looks like we may only be able to easily backport this to 9.x because we upgraded to Boostrap 5.x in that release. 8.x and 7.6.x ports don't seem to be easily possible.

So, I'm only flagging this for backport to 9.x.

[FrancescoMolinaro]

Hi @tdonohue , you are right I overlooked the label issue, I upgraded the library so that the select element will have an aria-label if a label or a placeholder is configured in the model, so that the accessibilty issue will be solved:

[tdonohue]

@FrancescoMolinaro : I've verified the accessibility bugs are all fixed, but I'd like to ask you to remove the final commit in this PR. It's adding a large number of unrelated labels to the en.json5 file (see comment inline below) along with other files.

In general, in a PR, you should ONLY add new labels that pertain to the PR (and they are only required in en.json5). Even though the other *.json5 files are outdated, we resync them with every release...so there's no need to resync them in this PR.

(Resyncing all the i18n files will also make this PR more difficult to backport to 9.x, as those will result in merge conflicts on that branch)

So, if you remove the final commit, it will make this PR much smaller (currently it is >20,000 lines) & easier to backport. Then only add labels that are required by this PR.

Beyond that, this looks great! It works and fixes the issues.

[tdonohue]

@FrancescoMolinaro : There are now a large number of unrelated labels added to this PR. Could we remove them?