Incompatible with ember-cli-ifa

[mansona]

I have a bit of a tough one that I am not entirely sure how to fix without a significant refactor 🤔

Essentially ember-cli-ifa is a somewhat popular addon that is used to allow you to lookup the assetMap generated by broccoli-asset-rev and dynamically reference assets for urls that are being generated dynamically (i.e. an image that has the same name as some data in a loop).

There have been some refactors on the ember-cli-ifa addon recently to make it more stable (and also fix a bug where it was causing integrity checks to fail in some cases) but these refactors have meant that it now depends on the presence of the assetMap at build time. Now that ddbeae1 means that prember runs before broccoli-asset-rev it is impossible for ember-cli-ifa to get access to the assetMap when running in the context of prember 😞

I have been wracking my brain trying to find the issue for the past month and now that I've found the root cause, it feels like there is no real solution to it. The only naive solution I can think of is that we need to split broccoli-asset-rev into 2 addons: one that generates the asset map and one that does the replacing. That way we would be able to prember run after broccoli-asset-map-generator but still before broccoli-asset-rev-replacer.

Obviously I would really prefer not to have to split broccoli-asset-rev in two as that is much more effort than I was hoping to have to spend to fix this one issue 😞 any guidance would be much appreciated.

[ef4]

I don't know how to say this without being harsh: broccoli-asset-rev is bad. Fundamentally bad. Safely doing automated editing of arbitrary code so that it will follow an asset rename is impossible.

It mostly works because mostly people do simple things, up until the point where it trolls you hard and you don't notice until things go to production.

An API more like ember-cli-ifa's is the solution: if you want to refer to an asset, you must go through an explicit API, either one that makes sense at runtime, or ideally one that makes sense at build time.

Once you have some explicit API (which ember-cli-ifa does), all of the unsound work that broccoli-asset-rev is doing is unnecessary. You don't really need or want it to go hunting for strings that look like the renamed filenames and replacing them in your code, because you're just going to find the right names via the asset map. So the circularity you're stuck on here isn't even necessary.

So overall I agree with your assessment, there is not a quick hack here that won't lead to even more trouble.

I think your best short-term path on projects that need this kind of thing is to stop fingerprinting the asset classes in question, and instead make sure your deployment handles cache invalidation another way. Fingerprints are a nice shortcut that simplifies cache configuration, but they're not strictly necessary. For example, if you deploy to cloudfront you can remove "*.png from the set of files that broccoli-asset-rev fingerprints and add *.png to the set of files for which ember-cli-deploy-cloudfront issues invalidations.

[mydea]

FYI, I have spent some time basically working around the same issue for ember-l10n, which uses the approach directly lifted from ember-cli-ifa (we use it there to build a map to fingerprinted locale files).

Cropster/ember-l10n#65

I'm not quite sure, but maybe a similar approach could work for ember-cli-ifa:

• Ensure ember-cli-ifa runs after broccoli-asset-rev
• Fetch all files in the postprocessTree() hook and build the asset map from there, instead of in postBuild()