Migration to NX and refactor of Utils and Core into libraries.

[FrancescoMolinaro]

References

https://wiki.lyrasis.org/display/DSPACE/DSpace+Angular+%3A+library-based+architecture+proposal

Work includes also #3997 as we started from there to avoid future conflicts.

Description

This PR is a follow up of the migration to standalone components done in DSpace 8, with the goal of a modular architecture.

The new code serves two main purposes, first it introduces NX in the project as build orchestrator, second it introduces two new libraries: Core and Utils.

Instructions for Reviewers

The app needs to be running as before and the commands to run it remain unchanged.

List of changes in this PR:

1. Migrated from an Angular CLI project to a NX standalone App.
   The Angular CLI has been replaced by the NX CLI.

2. Created two new libraries Core and Utils:
   2.a Moved all data services and related models into Core.
   2.b Moved some of the states from AppState to CoreState to isolate the library.
   2.c Replaced in the whole library the environment import with injection token.

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.

[github-actions]

Hi @FrancescoMolinaro,
Conflicts have been detected against the base branch.
Please resolve these conflicts as soon as you can. Thanks!

[tdonohue]

@FrancescoMolinaro : Now that #3997 has been merged, it'd be good to rebase this PR against main so that it's easier to understand the changes it is making.

To everyone watching this PR: as noted in Developer Meetings, I'm still not certain whether we'll be able to include this in the 9.0 release (as most other developers have not had experience with the changes in this PR & the changes seem rather significant). But, at the very least, I'd like to get more eyes on this so that we can make a decision as to whether to consider it for 9.0, or perhaps merge it directly after the 9.0 release (so that developers can get more experience with it prior to the 10.0 release).

[tdonohue]

@pcg-kk : When you have a chance, could you add details / links regarding the feedback you shared about Nx in yesteday's Developer Meeting? If, for some reason, you'd rather keep this feedback off of GitHub, you also could add it as a comment to the wiki page which describes this effort: https://wiki.lyrasis.org/display/DSPACE/DSpace+Angular+%3A+library-based+architecture+proposal (If you choose the wiki approach, let me know if you need an account. I just need an email to send your account signup to.)

Based on your feedback, I did a little digging on Nx support for Angular and their responsiveness to tickets in general.

• You are correct that they have a lot of open tickets & PRs, but the "Pulse" of the project looks good overall to me. They are merging more PRs than are being open & closing more issues than are being open: https://github.com/nrwl/nx/pulse This is an indication to me that they are constantly improving the software, and are responding to some issues. They also have regular releases with lots of beta testing: https://github.com/nrwl/nx/releases I know you mentioned you had several tickets that didn't get responded to though, so I'd definitely appreciate links to those tickets as it'd help us understand your experiences better.
• I tried to dig around regarding Nx support for Angular versions. The only information that I found was this page: https://nx.dev/technologies/angular/recipes/angular-nx-version-matrix That also looks promsing to me because the latest version of Nx supports Angular 18, 19, and 20 (i.e. all supported Angular versions). So, it's good to see that the version of Nx isn't closely tied to a specific Angular version (there's some flexibility there). But, it sounded like your experiences were also different here?

Thanks in advance!

[pcg-kk]

@tdonohue , sorry that I answered just today, but I was so busy last week. I would like to challenge a team with Angular CLI Workspaces. Did we think about that? Why do we resign from this flow if the reason for NX is just to introduce separate libraries?

Unnecessary Complexity for a Single Application

The DSpace project is a monolithic Angular application. NX's primary value proposition is managing multiple applications and libraries in a monorepo. Adding NX would introduce additional tooling overhead without corresponding benefits. Security updates and dependency management become more complex too, because of the NX dependencies and subpackages.

Established Build and Development Workflow

The project already has a well-established Angular CLI-based setup with standard configuration angular.json . Custom webpack configurations and build scripts are already in place. Migrating to NX would require significant refactoring of existing build processes and configurations for all users.

NX requires more knowledge about the process

The development team of DSpace consists of domain experts rather than large-scale enterprise developers. A lot of contributors don’t know NX's enterprise-focused features (affected testing, distributed caching), and we increase the level of complexity for them.

Deployment and CI/CD Simplicity

The current deployment model uses Docker with straightforward build processes. NX's advanced features like affected builds and distributed caching, are unnecessary for typical DSpace deployment scenarios. During daily work, there are almost no pros.

Maintenance Overhead

NX introduces additional dependencies and potential breaking changes across versions. We have zero influence on the project structure (it is decided by NX devs) and every time when they change it, a lot of existing projects have a problem updating to the new one version. In my opinion, it’s worth mentioning also existing projects. Recently, we had a huge structure update with a new Angular structure; now it will be another high migration effort with uncertain benefits for standard DSpace usage.

---

Why not just Angular CLI Workspaces?

And in the end, I would like to ask why we don’t use just Angular CLI Workspaces? It is built in Angular CLI, it supports libraries. It doesn’t change a structure, no new dependencies, no migrations with NX flow, no NX issues to solve for users.