I think it is quite popular to have the assets & asset map compiled into a docker image. If this command was a cache warmer instead of a separate command, you would have to warm up cache when building the image. If you're using anything but file cache – would it work? As you don't have all the runtime infrastructure available during build 🤔

I would keep both ways: the command and the cache warmer. The former for standalone usage, the latter for integrated usage with Symfony apps.

As long as it's not enabled by default or can be disabled, I can see the reasoning. However, this approach is more than just destructive for the cache—it affects more than that.

This is why it’s a compiler, not just a warmer: it relies on having all sources available.

Back-and-forth workflows are indeed common, but this change would force anyone using SASS, TypeScript, or custom assets to rebuild them every time they install the project or refresh their cache. I’m not sure this is an improvement.

To me, this doesn’t seem like the right solution. Webpack has faced similar challenges, but they haven’t been significant issues for most users.

Building "prod" assets locally also feels like a niche use case to begin with, and I honestly doubt this is a workflow for the majority of users.

That makes me question whether we’re addressing a real, widespread issue here. The potential cost and impact on everyone else seem disproportionately high.

We should optimize for the no-build stack. The path forward for asset mapper is certainly not to become yet another compiler stack. If one wants true compilation, then fine, use Webpack Encore or any alternatives.

The current DX is not as good at it should be. Having to learn/remember about running asset-map:compile when deploying (please acknowledge this aspect) or when switching to prod mode (you can call my workflow "niche", but show me numbers to support the claim - I like checking how things behave without the debug stack from time to time - and I claim I'm not alone (and I don't have numbers either ;) ))

And also having to remember undoing what asset-map:compile did to get back a working dev env is broken DX we have to fix.

I agree on all this.

I dont want to break anyone workflow or make it impossible to adapt.

For now it does.

And for now, even if you or me or anyone dont like it, the class and command are using the word Compile for a good reason!
Lets bring something new or better or différent to the table. But changing the nature of what it does currently and the way people use it (and how we documented and advocated for the last 12 months) make me very prudent here i admit.

And i’m not saying you’re the only one. I’m saying this will break a lot more usage of AssetMapper users than you think.

And this feels to me a big BC and not the best way to lead and convince people to the « no-build word ».

Let me come back later on this topic.