I'm not sure to follow, what would you like to do precisely ? Could you illustrate with an example, the file URL you'd like to expose, where, etc..

There is no way to know before the versionning the future URL hash, as it depends on the content of the file, which is ultimately decide during its compilation.

AssetMapper is not supposed to be "dynamic" in production. By that i mean you should compile and deploy your assets in the public/assets folder only once, when you deploy.

But if you need to then link to your files (ie: assets/styles/app.css you can use the asset function in your Twig templates, the Packages services in your PHP code, or simply check the public/assets/manifest.json file generated, it contains the whole map "local file -> versionned URL". You will then get the mapped public path of this file (ex: assets/styles/app-akpajan.css)

Now, regarding header and early hints, AssetMapper already does this for you (if you have WebLink component installed in your Symfony App.

If not, you can install it

 composer require symfony/web-link 

It automatically send these headers for every js module you do need on the page, and the critical css asset files too.

You can test the symfony.com website (that uses AssetMapper)

curl -X HEAD -I https://symfony.com

HTTP/2 103
link: </assets/vendor/bootstrap/dist/css/bootstrap.min-1712f0378f8675ca7cd423d6262fcccf.css>; as=style; rel=preload, </assets/styles/color-palette-d0d7a9d5fc86e4b1e9ad91ec0c957a96.css>; as=style; rel=preload, </assets/styles/app-39ad25b073804b5438d03471928d0b16.css>; as=style; rel=preload, </assets/styles/ui-components-4ded435d38615d6d791483e8861863ca.css>; as=style; rel=preload, </assets/@symfony/ux-live-component/live.min-5108f988fb2a3dbb292d6feebc9db7e8.css>; as=style; rel=preload, </assets/styles/search-42da4f901c7d6eabaf3c8671eb7664cf.css>; as=style; rel=preload, </assets/vendor/asciinema-player/dist/bundle/asciinema-player.min-a05dfa789a7206f64313b61ebd22be96.css>; as=style; rel=preload, </assets/styles/home-7f88a24d2c54119eca4a3c47aaf482ac.css>; as=style; rel=preload

HTTP/2 200
date: Sat, 23 Nov 2024 03:59:20 GMT
content-type: text/html; charset=UTF-8
cache-control: public, s-maxage=1200
link: </assets/vendor/bootstrap/dist/css/bootstrap.min-1712f0378f8675ca7cd423d6262fcccf.css>; rel="preload"; as="style",</assets/styles/color-palette-d0d7a9d5fc86e4b1e9ad91ec0c957a96.css>; rel="preload"; as="style",</assets/styles/app-39ad25b073804b5438d03471928d0b16.css>; rel="preload"; as="style",</assets/styles/ui-components-4ded435d38615d6d791483e8861863ca.css>; rel="preload"; as="style",</assets/@symfony/ux-live-component/live.min-5108f988fb2a3dbb292d6feebc9db7e8.css>; rel="preload"; as="style",</assets/styles/search-42da4f901c7d6eabaf3c8671eb7664cf.css>; rel="preload"; as="style",</assets/vendor/asciinema-player/dist/bundle/asciinema-player.min-a05dfa789a7206f64

[...]

As you can see, the first bytes of the response are already 103 preload links :)

Personal opinion: 99% of the time, the standard "prod configuration" of your hosting provider + following symfony performances advices will be more than "enough". And you would have a lot of other stuff to optimize before needing anything on this level :)

Hello smnandre, thank you for your answer and to challenge my idea!

Now, regarding header and early hints, AssetMapper already does this for you (if you have WebLink component installed in your Symfony App.

Sooo that's the critical point: If I understand correctly, by nature a request done on a PHP app can't receive early hints because it's made to create one and only Response; Sending early hints is something that would be done by an async "language", or by the webserver itself. So MAYBE I miss a point, but based on this I don't know how web-link & asset-mapper components deal with this limitation? And assuming this, I was pleased to see that (at least for Caddy) it's possible to "hardcode" a early hint on the webserver level.
IF I totally missed a thing, and web-link + asset-mapper are totally capable of sending early hints very early in the Request lifetime, no matter the webserver linked (Nginx, apache, IIS, ...), then my request is useless: don't read the following 😂 but if not, or it needs more steps to achieve, then maybe my request is legit (and somehow good)!

I'm not sure to follow, what would you like to do precisely ? Could you illustrate with an example, the file URL you'd like to expose, where, etc..

I think I over-engineered my ticket, so let me re-explain it:

• I'ld like to make a directive in my server (Caddy) to automatically early hints my "styles.css" because I know it will be mandatory in every pages of my app,
• I use asset mapper, and on production, it names my "styles.css" with a hash for versioning, that prevents me to prepare my server conf for early hints.

I think we can sum-up like this 😅 And the more I think about it, the more I feel like the good answer would be a configuration option to specify folders or files that would not be "versioned".

I showed you Symfony Framework with AssetMapper sends early hints, it is documented and you can test by yourself.
Also gave you a way to get the path you want.
There is a configuration to exclude paths for AssetMapper already.
And other ways to generate assets URL if you need to.

So really, I don’t think removing the versioning from AssetMapper would make sense here (it is one of its two main reasons to exist in the first place).

Hello,

I showed you Symfony Framework with AssetMapper sends early hints, it is documented and you can test by yourself. Also gave you a way to get the path you want. There is a configuration to exclude paths for AssetMapper already. And other ways to generate assets URL if you need to.

And I made my tests, read the whole web-link doc and repo, but I don't get how it can send a early hint. Note that I base all my research on this info that PHP send only one response and therefore can't send 1 103 and 1 200. If things changed since 2023 (pretty sure it didn't), I may be wrong about putting common css/js directly in server conf.

When I test with curl -I --http2 --trace-time -v https://symfony.com :
11:33:22.634959 * ALPN: server accepted h2
11:33:22.651598 < HTTP/2 103
11:33:22.660133 < HTTP/2 200
I see a difference of 9ms between the 103 and the 200, I may be wrong but it doesn't seem like the 103 was sent really far before the 200. But I can't really assume anything as the responded server is "cloudflare" and not nginx caddy or apache, I don't know if there is anything dynamic that will hit a database or even the server/deployment conf for this site.

Test with curl -I --http2 --trace-time -v https://ux.symfony.com :
12:07:57.878667 * ALPN: server accepted h2
12:07:57.912237 < HTTP/2 103
12:07:58.051407 < HTTP/2 200
140ms, better! But I don't know how it is deployed so...

If I look at web-link code, I may misunderstand something but it seems that the links are put in header on kernel response event, an event that is triggered after the controller's process. So I may miss the code where early hints are processed, but if I don't I'm pretty sure web-link can't do magic.

But if you need to then link to your files (ie: assets/styles/app.css) you can use the asset function in your Twig templates, the Packages services in your PHP code, or simply check the public/assets/manifest.json file generated, it contains the whole map "local file -> versionned URL". You will then get the mapped public path of this file (ex: assets/styles/app-akpajan.css)

Thank you, I'll check this as I may overlooked your paragraph here, sorry. Few (early) hints:

• I already use asset() function in twig templates as it's how assetmapper works already? Incredible examples of my real world app:

<link rel="stylesheet" href="{{ asset('styles/globals.css') }}" />
<link rel="stylesheet" href="{{ asset('styles/organisms/header.css') }}" />

• I don't know the Packages services, I'll check,
• If I check the generated manifest.json in public/assets, I assume it's already on production? So looking at the prod files to prepare the prod server conf is not really convenient. BUT the interesting part is you said that the hash is based on content? So If I do a asset-map:compile locally and I don't change the file, the name will be the same after deployment on prod?

So really, I don’t think removing the versioning from AssetMapper would make sense here (it is one of its two main reasons to exist in the first place).

My suggestion is not about stopping versioning, it is more about setting an option conf to tell for a given file or folder, "please don't version this specific one, I may need its name to be predictable for some reasons".

If you stop versioning the CSS file, you will run into caching issues. You won't be able to use a long cache lifetime anymore (as you would not have cache busting anymore, so the cache cannot be invalidated when the file changes), which is probably a lot worse for performance than not having early hints.

If you stop versioning the CSS file, you will run into caching issues. You won't be able to use a long cache lifetime anymore (as you would not have cache busting anymore, so the cache cannot be invalidated when the file changes), which is probably a lot worse for performance than not having early hints.

That's a very nice counter argument; If I understand, by disengaging the versioning on one file, we don't break the cache directly, but instead having trouble with long term caching when updating the file later?

As I'm very noobish/bad with hash and such, I looked how AssetMapper versions the files; It seems to use the php hash_file() function, and therefore the same file will always returns the same hash (as password checks I presume)? So I think the (my) way is now more to get the final hash locally, when the asset file's work is done, and use it on the server conf.

Do you think it's possible for bin/console debug:asset-map to have a 3rd column that will display the versioned name with current hash? Do you see any counter argument for that?

Do you think it's possible for bin/console debug:asset-map to have a 3rd column

A thrid column i'm not sure, as ouput is already too large.. but a asset-mapper:foo-bar command (no inspiration here) to get information on a mapped asset seems perfectly doable.

Just to be sure to understand, on which environment / debug mode would you run this command ?

Just to be sure to understand, on which environment / debug mode would you run this command ?

As version's hashes are done based on file content and will ever return the same result for the same file, I would launch asset-mapper:foo-bar on local dev or on prod and expect the same output?

Agree with the point that the debug:asset-map output table would be too large, but just to POC this, based on the fact that compiled paths & names can be predicted:

As version's hashes are done based on file content and will ever return the same result for the same file

Not exaxctly.

It may be the case for static CSS files without imports, no custom compilers, and no specific environment settings...

JS file can depend on other files, on theirs import path resolution, on differents settings or compilers, etc..

In fact, the hash is not simply based on the file content. It's based on the file content after compilation.

So in your situation, it should probably be the same value 99.99% of the time. Still, notice the "should": no promise or contract here. To illustrate, AssetMapper 7.2 has a different hashing algorithm than 7.1 .. i'd say even "logic" (that would not change in your case hereà). And people in your situation would have to change their configuration.

based on the fact that compiled paths & names can be predicted

Not sure what you mean.. is it an argument to add this 3rd column ? Because i really insist, a third is impossible. And project with AssetMapper and Stimulus (so... most of them), would display this

vendor/@hotwired/stimulus/stimulus.index.js       assets/vendor/@hotwired/stimulus/stimulus.index.js    assets/vendor/@hotwired/stimulus/stimulus.index-12345.js 

Impossible... except for who uses a 180+ columns terminal 😅

What is not working in the "one-asset-direct-debug-command" suggestion ?

In fact, the hash is not simply based on the file content. It's based on the file content after compilation.

OK I get it: launching the new command MAY return the same result as in prod, based on your stack (compilation, env conditions, etc.).

So a command that could be launched in any env, that garantees that it's the actual final name of the file but no garantee that it will be the same in any env, is quite good!

What is not working in the "one-asset-direct-debug-command" suggestion ?

Nothing, I just wanted to be sure that we have the same understanding of what's the '3rd forbidden output' looks like 😃

A new command like debug:asset-compiled is the right way, maybe with :

1. one optional parameter (the logical path) for one output (the compiled filename),
   • If no parameter, a 2 columns table 'logical path'/'compiled filename',
2. One mandatory parameter, same as above but without the no param scenario.

Does it feel good?

Could the third column just display the hash (e.g. 12345) instead of the full path with the hash (e.g. assets/vendor/@hotwired/stimulus/stimulus.index-12345.js?