amd-loading.js does not get a unique fingerprint

[timmorey]

The amd-loading.js script does not always get a unique fingerprint at build time, which can break deployments to environments that simultaneously host multiple revisions (for example the lightning deploy strategy). In particular, when a revision contains only changes to the app or vendor js files, the amd-loading.js script will not get a unique fingerprint.

This can be reproduced in the dummy app included in this addon:

1. Build the dummy app for production (ember build -e production). This will produce assets like

 - dist/assets/after-amd-loading-49ba473f2b98921e1454e73bbd5c5309.js: 154 B (91 B gzipped)
 - dist/assets/amd-loading-b1312b7f4f125360ce0fd4cd3a7ccf49.js: 535 B (374 B gzipped)
 - dist/assets/amd-loading-tests-a5bd3d73673838c1fc13645cfdaa7610.js: 367 B (256 B gzipped)
 - dist/assets/dummy-3a7c7f5af0c960f7a683a3f8570faeab.js: 6.86 KB (1.83 KB gzipped)
 - dist/assets/dummy-d41d8cd98f00b204e9800998ecf8427e.css: 0 B
 - dist/assets/vendor-a222ba9ee1f0c0d773cef70a9339063d.js: 501.41 KB (131.12 KB gzipped)
 - dist/assets/vendor-d41d8cd98f00b204e9800998ecf8427e.css: 0 B

2. Make a change to the dummy app that does not include any new amd imports and will only result in a change to the dummy.js asset. For example, add <div>hello world</div> to the application.hbs template.
3. Build the dummy app for production again. This time, we get the following assets:

 - dist/assets/after-amd-loading-49ba473f2b98921e1454e73bbd5c5309.js: 154 B (91 B gzipped)
 - dist/assets/amd-loading-b1312b7f4f125360ce0fd4cd3a7ccf49.js: 535 B (373 B gzipped)
 - dist/assets/amd-loading-tests-a5bd3d73673838c1fc13645cfdaa7610.js: 367 B (256 B gzipped)
 - dist/assets/dummy-9cfba068dfb7c1876d95efa82d6a45aa.js: 6.91 KB (1.85 KB gzipped)
 - dist/assets/dummy-d41d8cd98f00b204e9800998ecf8427e.css: 0 B
 - dist/assets/vendor-a222ba9ee1f0c0d773cef70a9339063d.js: 501.41 KB (131.12 KB gzipped)
 - dist/assets/vendor-d41d8cd98f00b204e9800998ecf8427e.css: 0 B

Notice that the dummy.js file got a unique fingerprint here, but the amd-loading.js fingerprint is the same as in the previous build, even though the new amd-loading script correctly references the new dummy script.

If we were to then deploy both of these revisions to a hosting environment, both would end up loading the same dummy.js file -- the two revisions will not be able to coexist. Thus the deployment is broken.

The fingerprint of the amd-loading script will only be changed when the amd imports in the app are changed.

I believe this is due to the way fingerprinting is done in ember-cli. Fingerprints are first computed for all assets, and then the asset files are later re-written to preserve references to other fingerprinted assets. So, a new fingerprint on the dummy.js or vendor.js file does not lead to a new fingerprint on the amd-loading.js file.

Our team uses the lightning deploy strategy in our QA environments where we host many revisions at once for different lines of development. We also use this strategy in the production hosting for one of our apps. For the time being, we have reverted to using ember-cli-amd 2.x, since it appears that 3.x is incompatible with the deployment strategy. However, we would like to update to 3.x so we can benefit from other changes happening here.

One solution might be to provide an option to inline amd-loading.js into index.html at build time for use cases that are dependent on unique fingerprints.

[timmorey]

The root issue here appears to be down in broccoli-asset-rev: ember-cli/broccoli-asset-rev#29, but looks unlikely to get fixed there.

[timmorey]

Resolved with #60