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 make just 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 the only 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. Both MappedAsset and AssetDependency are objects that hold scalars. For example, here is a dump of one situation (dumping the result of the unserialize 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 on asset2.css. When something asks for the asset1.css asset, its cache is fresh, so we get back MappedAsset instances from the cache for both asset1.css and asset2.css.
• Meanwhile, asset3.css also has a dependency on asset2.css. When something asks for the asset3.css asset, its cache is NOT fresh, so we get back FRESH MappedAsset instances for both asset3.css and asset2.css.

So, at this moment, there are two distinct asset2.css MappedAsset 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 for MappedAsset::addDependency(). But, in practice, once a MappedAsset is returned from AssetMapper, it is intended to be read-only: its data is entirely set during the creation process (we could even "enforce" this by adding some flag to "freeze" the MappedAsset and thus reject calling addDependency(), but that might be overkill).

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

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