Hi Javier!

Thanks for using AssetMapper and taking the time to give your thoughtful feedback and questions - I really appreciate it :). I've commented, but some are signs of growing from one way or doing things to another. Something feels weird because it's different than before... but it's really fine / not a big deal. I also know that even if that's true, if you ask these questions, other people will too. So let's answer them and make changes / add things to the docs before people need to ask them!

1. Unconditional shim loading

Hmm, that's an interesting idea. It would actually mean MORE code (in your HTML source) that would need to be downloaded on every request, but it's probably worth it - at least proposing. We should also add the integrity hash, as you mentioned, in any situation.

If we want to get really crazy, we could put the JS you proposed (once tested, of course), into a tiny new shim.js file in symfony/asset-mapper. Then have framework-bundle expose this asset path to AssetMapper. Then the script would be something simple like:

<script src="/assets/framework/es-modules-shim.js"></script>

It would still, ultimately, write a link to the CDN (unless the user has downloaded the file locally - which you can do... so a few details to think about).

2. Full importmap loading

Yup! We should likely make this clear in the docs, but hiding details is not security anyway. And these paths were actually always available via the public/manifest.json file. They're just more obvious now, so we notice them.

3. CSS/JS Comments are fully exposed

Same as above. It's an issue for documentation. You should not care :). After documenting it clearly, if you have some super-private site where your public assets contain sensitive comments, you can activate a minification layer during your deploy / in your infrastructure.

4. Strange CSS entries in importmap

That's a necessary evil. You actually cannot import './some-file.css'. True JavaScript ONLY allows you to import JavaScript files. The importmap entries are how we get around this: when you import a CSS file, it actually imports this tiny JS snippet, which avoids making it fail. We could (for normal, non-async imports) remove CSS imports (i.e. AssetMapper sees the import './file.css', adds a link tag for it, but then removes the line from the final JavaScript so that it's not actually executed). That would remove these entries (except for async CSS imports, but these are rare and that's a tiny price to pay for them). We haven't done that because we are trying, in every possible case, to serve your source files directly with zero changes.

5. No PurgeCSS

I don't care because I'm using Tailwind, but it's a valid thing to ask about. If someone wants this, they can definitely do it, or even create a bundle:

A) Use https://github.com/postcss/postcss-cli
B) Add & configure purgecss
C) Run postcss and point to your assets/styles/app.css file and output to assets/styles/app.output.css. Then that is what you import from app.js: import './styles/app.output.css';

The bundles like SassBundle & TailwindBundle are just tiny wrappers to download the necessary binary and use some magic to avoid step C (they make AsssetMapper think the content of app.css is actually the content of app.output.css internally so that you can continue importing app.css and not care about things).

1/ I'm 100% with you on that one (and i personnally won't use this polyfill), but it's the "less worst" solution ... The DomContentLoaded option would not work in the same way

There is a seamingly better option explained there : https://philipwalton.com/articles/loading-polyfills-only-when-needed/

TL;DR; (copied from this article)

if (browserSupportsAllFeatures()) {
  // Browsers that support all features run `main()` immediately.
  main();
} else {
  // All other browsers loads polyfills and then run `main()`.
  loadScript('/path/to/polyfills.js', main);
}

function main(err) {
  // Initiate all other code paths.
  // If there's an error loading the polyfills, handle that
  // case gracefully and track that the error occurred.
}

More generally, and after the recent issues / comments / suggestions on AssetMapper, i believe there is something to clarify between the ImportMap "component" in Symfony LAST stack, and the importmap technology...

I for once would not want to mix JS files with static assets, SVG sprites, LESS source code etc etc... But i fully understand it may be the need / desire of many developpers.

So i guess it's probably also a question of "marketing" and communication on "what can/not be done -- what should/not be done" with this (incredible) component :)

Thanks for the answers and comments to my questions. Everything is more clear now.

So, only two issues remain to be fixed:

• Add the integrity hash to the shim link - Fixed in [AssetMapper] Add integrity hash to the default es-module-shims script #53251
• Don't load the shim unconditionally - Still pending

Thanks

(I've reopened this issue because there still one pending task.

Note: we can decide to NOT implement the pending task ... but let's make a decision about it. Thanks!

As i have no access to older computers / browsers, i'm not sure i'll try the last task soon :/

The polyfill you're talking about here is the one that can be disabled via importmap_polyfill, right?

=> Then this issue can be closed.

Nope :)

See the uncheck point on @javiereguiluz TODO just before in this issue.

We are experimenting on ux.symfony.com right now, but the question to implement this feature per default on AssetMapper is still very open.

Let's close this one as fixed because we now load the shim only when needed (see symfony/ux#1381). Thank you all!

@javiereguiluz @weaverryan i am not sure if this change doesn't make things worse.

i was really shocked as i noticed that a file was loaded from a CDN as i used the asset mapper the first time. i have a strict no-CDN policy. it was a real wtf moment. first i thought i got hacked somehow. i headed to the docs where i found no explanation searching for polyfill (yes sometimes you overread a big green box xD). a colleague pointed me to the right direction php bin/console importmap:require es-module-shims

• according the GDPR ips are personal data.
• in austria we had a massive lawsuite about sideloading google fonts (ip is transfered to google without consent) which was took down because so many people where hit by it but in the strict sense the exposing of an ip address to a 3rd-party is still a problem.
• many pages switched to serving fonts from their own domain or added it to the "consent banner" where the external files are loaded AFTER the users gave their consent.
• if the change from [Site] Load importmap polyfill conditionnaly ux#1381 hits the flex receipe of assetmapper the sideloading is kind of hidden. on my local machine where i have an uptodate browser i won't see that something is sideloaded but if a user comes to the site with an old browser, suddenly something is sideloaded and the developers may not even know about (again ONLY if this change goes into the default receipe).

i would argue for a strict opt-in solution. NEVER sideload something except the developer explicitly requested this behavior. so i think we should always use a local polyfill file per default if importmap_polyfill is true

i am not sure which way you will go after the merge of PR symfony/ux#1381 will this solution find its way into a flex recipe where suddenly something is sideloaded by default? we should keep this issue open or maybe even create a new one to be quite explicit and transparent about this.

Let's close this one as fixed because we now load the shim only when needed (see symfony/ux#1381). Thank you all!

We do on ux.symfony.com, but this is not the default behaviour of the AssetMapper in the framework

I do believe we should make this polyfill optional, as importmap is available on 92% browser according to caniuse.com, but depending on the region/country it can be way more than that

Example: Caniuse evaluate IE market share at 0.45%, but in France it's now around 0.10%...

if the change from symfony/ux#1381 hits the flex receipe of assetmapper the sideloading is kind of hidden.

@c33s : That PR concerned the website of Symfony UX, never was intended to be ported back "like that" on symfony/symfony. We wanted to see if not adding the polyfill for everyone was going to create problems. And we tested some asynchronous loading. But i insist, that was a live test on a website, not a PR for the asset-mapper component :)

i would argue for a strict opt-in solution. NEVER sideload something except the developer explicitly requested this behavior. so i think we should always use a local polyfill file per default if importmap_polyfill is true

I 100% agree with you

@javiereguiluz could you reopen please ? (as i understand it you closed because you did think the ux PR was ported on symfony framework, sorry if i'm wrong)

Let's reopen then. Sorry!