Preparation work for modularization / library-based approach

[atarix83]

References

• Related to architectural cleanup and modularization https://wiki.lyrasis.org/display/DSPACE/DSpace+Angular+%3A+library-based+architecture+proposal
• This will replaced the first migration PR Migration to NX and refactor of Utils and Core into libraries. #4019

Description

This PR refactors and reorganizes the codebase to support a future migration to NX. The migration itself is not included in this PR—this is a preparatory step to make the transition smoother and more maintainable.

Instructions for Reviewers

This PR focuses on architectural improvements and code cleanup. The goal is to isolate core logic and reduce inter-module dependencies, paving the way for a modular NX-based structure.

Although the PR may appear large, most of the changes are due to updated import paths for core, config, and utils, which have been simplified to reflect how these modules will be used as libraries after the NX migration.

The guiding principle behind this refactoring is that each library (core, config, utils) should be fully isolated, with no dependencies on other parts of the application. This ensures a clean separation of concerns and aligns with NX architectural best practices.

List of changes in this PR:

• Isolated core, config, and utils folders by removing dependencies between those "modules" and other parts of the application
• Moved notifications and correlationId state into the core state
• Reorganized classes and files to reflect a clearer modular structure
• Simplified import paths for core, config, and utils to reflect how they will be used as libraries after the NX migration
• General code cleanup and removal of circular dependencies

How to test this PR:

• Ensure the application builds and runs correctly
• Verify that notifications and correlationId functionalities are still working as expected
• Check that there are no unnecessary dependencies between modules
• Evaluate how well the different parts of the application have been isolated
• Identify any remaining classes or logic that should be moved into core, config, or utils to complete the modularization

Checklist

• 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 @atarix83,
Conflicts have been detected against the base branch.
Please resolve these conflicts as soon as you can. Thanks!

[artlowel]

@atarix83 My feedback, as discussed in today's meeting:

• It's currently a bit arbitrary where guards, resolvers, and route paths are located. A few are in the core library, but most are still in app. I ran into a problem with this for endUserAgreementGuard, which is in the core library, but needs paths from info-routes.ts, which is in app.

  • In my opinion it makes the most sense to keep all guards, resolvers and path definitions in app for the moment, until we can split it up further. That way core contains things like models and services, i.e. the very low level stuff, while things that are related to actually rendering the web app stay in app for now. Eventually they can ofcourse move to a separate library.

• src/app/core/auth/models/normalized-auth-status.model.ts is empty

• CorrelationIdService contains a console.log

[github-actions]

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

[artlowel]

Thanks @atarix83!

[tdonohue]

👍 Thanks @atarix83 ! I gave this a re-review today, and tested as much of the application as I could. The code looks good and I couldn't find any issues.

[alexandrevryghem]

I noticed this PR isn't working in dev mode. It seems to impact ts-node scripts that use tsconfig.ts-node.json with the new import statements

[tdonohue]

@atarix83 : Could you or someone on your team look into @alexandrevryghem 's report above? I can verify that it appears npm run start:dev no longer works properly with this PR in place. I had concentrated my testing on production mode (npm start). It appears we overlooked testing developer mode more thoroughly

[atarix83]

@alexandrevryghem @tdonohue we'll take a look

[AndreaBarbasso]

@alexandrevryghem, @tdonohue, I opened #4809 and the linked #4810 PR to fix the issue.