Split DamModule into composable sub-modules

[VPS-thodax]

Problem

DamModule registered file handling, image scaling, the block transformers and the dependents resolver as a single unit. A project that only needs DAM file upload and storage therefore had to bring ImgproxyModule and DependenciesModule along with it.

Computing the dominant color of an uploaded image was the one place where FilesService used imgproxy, which is what made that dependency reach into file handling at all.

Solution

DamDominantColorService now holds the dominant color computation, and DamModule is a facade composing four sub-modules. DamModule.register() keeps its signature and still composes all of them.

Module	Responsibility	Depends on
DamFilesModule	file and folder CRUD, upload, storage, serving, dam-items, media alternatives, licenses, warnings	BlobStorageModule, UserPermissionsModule, MikroORM
DamImagesModule	image scaling and serving, dominant color, image validators, FileImagesResolver	ImgproxyModule, BlobStorageModule, UserPermissionsModule, MikroORM, DamFilesModule
DamBlocksModule	the four DAM block transformer services	DamFilesModule, DamImagesModule
DamDependentsModule	the dependents field on DamFile	DependenciesModule

FilesService receives the dominant color calculator through the optional DAM_DOMINANT_COLOR_CALCULATOR token, which DamImagesModule provides. Without that module, uploads skip the color and FilesService.calculateDominantColor returns undefined. The contract is a standalone interface (DominantColorCalculatorInterface), so the files code has no runtime link to the imgproxy-backed service — the emitted files.service.js contains no require of anything under dam/images.

DamModule and each sub-module throw when they are registered more than once in the same process. A second registration would mount the DAM routes twice and add the dependents field to the file type again, so it never worked as intended.

FileImagesResolver moved from dam/files/ to dam/images/, so its folder matches the module that registers it.

Decisions

• DamFilesModule is the only sub-module that is exported. It is the one a project can register on its own. DamImagesModule, DamBlocksModule and DamDependentsModule each need providers that DamFilesModule registers, so exporting them would offer combinations that fail at DI time. DamDominantColorService stays internal for the same reason — it is an implementation detail of DamImagesModule, reachable through FilesService.calculateDominantColor.

Verification

• Demo API boots with DamFilesModule, DamImagesModule, DamBlocksModule and DamDependentsModule all reporting initialized dependencies, and registers the cms.dam.calculateDominantImageColor command
• schema.gql and block-meta.json regenerate unchanged, so the split does not affect the GraphQL schema

Outlook

The goal is that DamFilesModule can be registered on its own with as few dependencies as possible, for a service that only stores and serves DAM files:

DamFilesModule.register({ damConfig, Scope: DamScope, File: DamFile, Folder: DamFolder });

What DamFilesModule still needs to resolve:

Dependency	Injected by	Provided by	Status
BlobStorageBackendService	FilesService, FoldersService, FilesController	BlobStorageModule	stays — the DAM has to store files somewhere
EntityManager / MikroORM	most providers	MikroOrmModule.forRoot	stays
ACCESS_CONTROL_SERVICE	FilesController, FoldersController	UserPermissionsModule	optional in #6153

[VPS-Obi]

Out-of-scope: I don't remember why we initially exported this resolver, but IMO this shouldn't be part of the public API.

[VPS-Obi]

Needs human review — large diff, foundational for an auth-related change.

10 commits, +408/-216 across 16 files, splitting DamModule into four composable sub-modules (DamFilesModule, DamImagesModule, DamBlocksModule, DamDependentsModule) and moving dominant-color calculation behind an optional injection token. Verification relies on manual "Demo API boots" checks and unchanged schema.gql/block-meta.json rather than new automated tests for the module split itself. It's also base for #6153, which changes DAM authorization logic, so getting this structural change right matters. Already has 3 inline review comments, so review is in progress.

---

Generated by Claude Code