Asset Mapper

Hey Yoyo,

You’re right, out of the box, AssetMapper doesn't provide automatic page reloading when a file (like a Twig template, CSS, or JS file) changes. It's designed to be lightweight and doesn't include a dev server like Vite or Webpack Encore does.

I think it's possible to achieve autmatic reload, though personally I've never tried that. Take a look at the browser-sync NPM package. You will need to install it via Node, so it means you still would need to have node installed, but for local dev env it should be ok I think. And in theory, something like this should work:

npx browser-sync start --proxy "https://127.0.0.1:8000" --files "templates/**/*.twig, assets/**/*, public/**/*" --no-open --reload-delay 200

Let me know if that helped :)

Cheers!

Oh nice great idea thanks a lot for your help !

You're welcome! I hope that will work that way. Feel free to share a working solution with others if that will be a different from what I described, it may be useful for others too I think :)

Cheers!

Hey @Johann!

For example this beautyfull Space Inviters Logo img-tag. If i hover over {{ asset('images/logo.png') }} in my twig template and everywhere, Phpstorm just tells me "Missing asset".

💯 me too. I believe this is something that will need to be updated with the Symfony + PhpStorm plugin. It looks like there's an issue about it - https://github.com/Haehnchen/idea-php-symfony2-plugin/issues/2236 and the author has been pretty responsive and supportive for AssetMapper support. So hopefully it can be added :).

Cheers!

Hey Hugo-Le-Goff,

Yeah, good question! And as always, it's a tradeoff. AssetMapper currently does not directly support downloading assets from private repositories, as it relies on GitHub repository URLs or local paths to fetch assets. However, there are a few workarounds you can use:

• Use a Pre-Fetched Asset: Download the private repository manually (or using npm with your .npmrc file) and place the required assets in a folder in your project. Then, you can map the assets in your assets/ directory and include them in the importmap.

• IIRC you can extend AssetMapper with a custom Command. You could create a custom Symfony console command or script to use npm or yarn to fetch the private package using your .npmrc configuration or copy the relevant files into the assets/ folder for Asset Mapper to handle.

• Serve private assets via a CDN. If your private repository allows it, upload the required files to a private or authenticated CDN and reference them directly in your project via URLs.

Unfortunately, Asset Mapper's design intentionally avoids dependency on npm or similar tools to keep things lightweight, but this means it doesn't natively support features like .npmrc integration.

I haven't done those workarounds myself but IIRC they should be a valid solution with AssetMapper. Otherwise, you may still need to consider something more complex like Webpack Encore.

I hope that helps!

Cheers!

Hey @Nicolas-S

Good catch, yes, that causes problems with the dev environment. From my point of view, it will be good to add some check for static file exist, and if it does not exist, then pass it to the listener.

Cheers!

Hey @kinadian!

I might know what's going on :). If you open a 404 URL in your browser, what do you see? Is it a Symfony 404? Or a generic 404 from your web server? The key to loading assets in dev is that the asset URLs need to be processed through Symfony. In other words, when a request is made to /assets/app-abcd123.js, that request needs to be processed by Symfony. Sometimes a web server will, by default, see the .js and only look for that physical file (then trigger a 404 if it's not found). If I'm correct, check the rewrite rules on your web server. This won't be an issue on production, as you've seen, but you'll definitely want to get this working locally.

Cheers!

Hi @weaverryan!

Thank you. I asked a colleague to help. We ended up getting it fixed by installing symfony/apache-pack. This added an .htaccess file which changes apache's behaviour to let the request get processed by Symfony instead of returning a 404.

You were right, the 404 was a generic one from apache, not the Symfony 404 page.

Nice work! If you're using Apache, that is 100% the correct thing to do. I'm happy you got it sorted. Now, onward :)

Thanks for sharing this! There was a but introduced in some version of AssetMapper related to the comment. I believe that should be fixed in 6.4.4 and 7.0.4, which will release very shortly after this comment.

Cheers!

Hey @Senet!

Ha! I like the challenge - let's see if we can get you the rest of the way there :).

The only thing that's holding me back, is that I do not see any examples or documentation on how to add integrity hashes for styles/scripts. Is this possible with the Asset Mapper?

You're right to catch this. It is not yet implemented - we did a LOT for 6.4 (and this was on my list), but it didn't quite happen. It became less of a priority because AssetMapper 6.4 (unlike 6.3) doesn't rely on serving content from CDNs. However, I recognize that some people may still want integrity hashes even if their assets are being served from the same hostname or perhaps if you use AssetMapper but still offload the serving of the files to your own CDN (am I listing one of your use-cases accurately)?

So right now, there is no hook in AssetMapper to add those, though it should be super easy to add. AssetMapper already knows the content of each asset and is responsible for rendering the script and link tags... so I can't really see a problem. However (and I'm not an expert at all on this topic), while we an add an integrity hash to any link or script tags on the page, if app.js has import './foo.js', there is no mechanism currently to enforce an integrity hash on foo.js. You can read some discussion about it here - https://github.com/WICG/import-maps/issues/221. But even in that discussion, people are mainly talking about the importance of this when referencing assets on CDNs... and AssetMapper doesn't refer to CDN URLs. So, overall, I'm not sure HOW needed integrity hashes are... but I recognize that people (beyond you) will likely ask about this also.

Cheers!