This is the ugliest part of this PR, and it's actually a small fix so that decorating the AssetMapper will work properly.

• It's super convenient for compilers to have access to the AssetMapper
• But, we get a circular reference: AssetMapper -> MappedAssetFactory -> AssetMapperCompiler -> AssetMapper

Is there a more elegant way to makejust this one dependency lazy?

You could inject a lazy proxy here, using the same kind of trick than used when using#[Autowire(lazy: AssetMapperInterface::class)] for autowiring. But this would make the component much harder to use standalone if the circular dependency is between constructors (as theonly way to instantiate the object graph would be through a lazy proxy)

But this would make the component much harder to use standalone

Thank you - that makes me want to keep this as it is :)

what about using a closure here, that'd return the mapper? that's a service_closure inthe DI world

I don't think we can keep this as is TBH.

I'll fix this up shortly!

Given that the MappedAsset object contains AssetDependency objects that contain other MappedAsset objects, what happens when you serialize and unserialize those ?

Also, what is the impact of unserializing a MappedAsset with dependencies that will have MappedAsset objects not known by the AssetMapper internal cache (while potentially referring to the same assets) and also different from MappedAsset created for dependencies of other cached MappedAsset ?

Given that the MappedAsset object contains AssetDependency objects that contain other MappedAsset objects, what happens when you serialize and unserialize those ?

It seems to work fine, in practice. BothMappedAsset andAssetDependency are objects that hold scalars. For example, here is a dump of one situation (dumping the result of theunserialize in the cached factory) in a test project:

What concerns do you have?

Also, what is the impact of unserializing a MappedAsset with dependencies that will have MappedAsset objects not known by the AssetMapper internal cache (while potentially referring to the same assets) and also different from MappedAsset created for dependencies of other cached MappedAsset ?

I think I understand what you're referring to. So, for example:

• asset1.css has a dependency onasset2.css. When something asks for theasset1.css asset, its cache is fresh, so we get backMappedAsset instances from the cache for bothasset1.css andasset2.css.
• Meanwhile,asset3.css also has a dependency onasset2.css. When something asks for theasset3.css asset, its cache is NOT fresh, so we get back FRESHMappedAssetinstances for bothasset3.css andasset2.css.

So, at this moment, there are two distinctasset2.cssMappedAsset objects floating around the system. Their data is equal, but the objects are not identical. Other than being wasteful, I don't think it's a problem.MappedAsset objects are "read-only" informational objects. Well, except forMappedAsset::addDependency(). But, in practice, once aMappedAsset is returned fromAssetMapper, it is intended to be read-only: its data is entirely setduring the creation process (we could even "enforce" this by adding some flag to "freeze" theMappedAsset and thus reject callingaddDependency(), but that might be overkill).

However, if we're concerned about this, wecould, "refresh" the dependencies after fetching a cachedMappedAsset - e.g. loop over$mappedAsset->getDependencies()... grab the->logicalName +->getSourcePath() of each, call$this->createMappedAsset($logicalName, $sourcePath) on each, then "replace" theMappedAsset on each dependency.

tl;dr I don't see any real problem, but I could add extra code to be absolutely sure.