Should we keep one warmer but inject kernel.debug to determine if files should be removed? Without contraindication, this would be easier to maintain

This would mean creating (or even keeping) services for nothing. Not sure it'd be easier to maintain also.

Oh, by "the one for debug should remove files", you mean "remove files and nothing else"? If yes, indeed two warmers are more relevant, I'l do the change.

Like in #59073 yes

Second cache warmer added!

Ok so definitively we should not do this (or exactly like this).

AssetMapper generates during compile-command its config files.

They are not just cache files, as without it in production the assets won't be served.

But it wont be possible to rebuild them with this warmer if some cache:clear is executed (so massive BC break already).

Also these files are not in the cache directory, but in the public/assets directory.. that it self may not be available or writable then.

Some binary may also not be available in production (Sass and/or Typescript users are not a minority), so the recompilation of assets won't be possible there.

If I understand correctly, do you advise to not have this cache warmer at all?

After chatting on Slack, what @smnandre means is that in prod mode, the cache warmer will try to compile the assets, which can break, because the preconditions to compile them might not be met (tyically because the assets where compiled ahead of deployment, in a container that doesn't have the required binaries).

This is a concern we should address indeed. Running cache:clear in prod mode shouldn't be destructive as it is now.
For thoughts.

Using a cache warmer instead of a manual or explicit “compile” command would be potentially destructive on three levels and useless on one.

Destructive

Deletion of Critical Files
The suggested implementation starts by deleting both public/assets/manifest.json and public/assets/importmap.json. These files are absolutely vital at runtime for generating the import map and managing any asset links.

Risk to Asset Integrity
During compilation, final asset files are written directly to the public/assets directory instead of a dedicated cache or build directory. This means that any problem during the warm-up phase could endanger the integrity of the asset files, potentially resulting in incorrect URL references in the import map or manifest (if they still exist). Additionally, backing up the entire assets directory does not seem like a reasonable solution.

Fallback to Raw Source Assets
If these critical files are still present, the asset mapper will use the raw source assets from the repository. Without compilation, this would break functionality for anyone using SASS, TypeScript, React, or simply needing to bundle files.

Useless Heavy Resource Consumer

Resource-Intensive
The asset-map:compile command, which generates the import map and entry point files, needs to browse and cache metadata about every file in the assets folder. This process is resource-heavy, especially since asset files are often not hosted on the same server/container/image as the PHP code once deployed.

Redundant Caching Efforts
There is no need to populate the cache with data that won’t be used afterward. Symfony applications theoretically have nothing to do with assets once in production. The CompileCommand and the CacheConfigReader were designed to avoid this by ensuring that, in production, the cache is not used and only the necessary files are utilized.

I now strongly believe that, today, a cache warmer (in production) introduces far more problems than it solves.

(P.S. I asked GPT for help to fix my English.. as it seems I have real difficulties expressing my thoughts and being understood these days.)

I don't think the issue is with using a cache warmer on its own. But the implementation of the cache warmer needs to be carefully designed to handle these aspects you raised.

I don't think the issue is with using a cache warmer on its own.

Well i'm less and less sure about that to be honest.. As the cache has not much role to play once in production. So there is no real reason to "warm" anything here but there is to ... (not nitpicking) .... "build".

But more generally: of course, it's an AssetMapper / assets "problem" more than a "cache" one...

There are multiple things we should/need to improve on that side:

• stop mixing env/dev assets
• allow some form of rollback
• store internally (var/build ? cache ?) the files I talked about earlier ...
• ... and having one file per env, removing de facto the problem of switching back and forth from prod to dev (no built prod confg file would be used then)

I also think we need some other changes/improvments (not strictly related to this particular implementation, but somehow addressing the same topic)

• clarify command names (probably more "component names & reponsabilities"): assets:install deploys bundle assets only, asset-map:compile deploys and compress assets assets:compress, importmap:install does another thing, while composer install has an effect on all this too with flex & stimlus bundle, framework "asset" configuration too, ...
• add one page par "system" (asset mapper / webpack) named "handle assets with .." , listing very straightforward instructions on how to "install / update / deploy" assets + most frequent use cases / needs
• introduce extension points filling users need the more (ex: import map entries or splitted stimulus config)

But I think all this requires time and some form of coordination..

Also, i need to say out loud that despite the impression this discussion may give, i'd love to have a real "zero-build" mode available and i'd be the first one to enable it... on my personal projects ;)

Let me close as objections are valid IMHO. We need to figure out another approach...