Fastboot, ifa, and vedor SRI hashes

[adopted-ember-addons]

Fastboot, ifa, and vedor SRI hashes

[YoranBrondsema]

I was bit by the same bug but with a different consequence. I only modified an asset. This caused the asset map to change but vendor.js remained the same. Even though ember-cli-ifa modifies vendor.js, it does not modify the fingerprint. Therefore, the deploy addon ember-cli-deploy-s3 didn't upload the modified version of vendor.js as it assumes that when the fingerprint is the same, the file hasn't changed.

So basically, the main cause is that this addon breaks the same fingerprint === same file invariant. This can cause problems for situations where this invariant is assumed, e.g. during deploy or with caching by a CDN.

We could regenerate the fingerprint for vendor.js here but that require an update of the asset map fingerprint, which would require an update of vendor.js by this addon, which would regenerate the fingerprint for vendor.js, ad infinitum... so that wouldn't work.

Alternatively, if the asset map is not fingerprinted, this solution could work.

I'm open to discussing this and fixing this case!

[Turbo87]

this should be resolved by #40 AFAICT

[eco3162035]

Hi there,
After further examination, this issue has nothing to do with fastboot.
I realize I have been brief on the issue, in order to reproduce, create an ember app and enable ember-cli-sri and ember-cli-ifa, configure both. Run the app, and it will not load due to modification of vendor.js after a hash has already been generated for it.

[RuslanZavacky]

@YoranBrondsema yeap.. as you've described. I suppose to overcome this, you can make assets inline or we might think of fallback to a previous option that we had - separate assets filename to load before app loads.