Automatic Subresource integrity attributes management for bundles

[ghidello]

I'm planning to host my application static resources, bundles included, on a CDN so I started tackling the problem from the Subresources Integrity attributes creation and management. The basic idea is to have a new option in the aurelia.json build object that, when enabled, will trigger the following actions during the building phase:

1. Compute the hash of the bundles (except the main one)
2. Update the requirejs configuration to emit the SRI attributes with the computed hash when requesting a bundle
3. Compute the main bundle hash
4. Update the index file with the SRI attributes for the main bundle

My current solution lives here for now but i was wondering if this kind of feature can be useful for anyone else before thinking to make a pull request.

[JeroenVinke]

@AStoker what do you think, feature-wise?

[AStoker]

You know, there are a lot of neat things/features that you can add onto the CLI since it's just using gulp tasks. For example, I have a whole locale object in my aurelia.json that configures a tool I made to localize my entire application. These kinds of enhancements are helpful to multiple people, but not necessarily everyone. That being said, things like this I think would be great to add to our recipe list (https://github.com/aurelia/cli/issues/393). It almost makes me wonder if we could have some kind of packaged tasks that people could pull down via npm and use inside the cli... You want a translate task, go download it and just use it. Want a task to configure your project for a CDN, bam, here it is. That keeps some of the fluff that other people don't need out, but makes it easy to add things into it...

[JeroenVinke]

You know, there are a lot of neat things/features that you can add onto the CLI since it's just using gulp tasks

That's very important, yes. How would you feel about opening up the build system a bit more, allowing you to hook into more things

[AStoker]

I think that could be incredibly powerful/helpful. I think we'd get more bang for our buck by keeping the CLI streamlined, but allow it to be "plugged" if you will, so people can add any which feature they desire. Right now you can (mostly), but it's not necessarily intuitive on how. Perhaps a bit of refactoring to include a few lifecycle callbacks of the build process could go a long way.

[ghidello]

Indeed having this kind of extensibility and a plugin system would be very nice: for my current implementation I simply followed the code for the "rev" option and so I polluted quite a bit the poor bundle.js file, which is already pretty busy by itself, and a number of other core modules. For a pull request my code should be definitely refactored out in a new module and hooked somehow in the main flow. As @AStoker said, I thought to put my logic at the gulp level but I gave up immediately on it because the steps I need to do happen in different moments:

1. compute the hash of the "non main" bundles waiting for their minification (if needed)
2. wait for the bundle file name to change if the "rev" option is enabled
3. update the requirejs config object with the hash handling logic
4. wait for the main object to be minified and renamed if needed
5. compute the main bundle hash and update the index file

So, again, having those hooks in the core modules looks very compelling to me. One way to bootstrap this process can be transforming the current "minify" and "rev" options to plugins so we could streamline a bit the bundle.js file and prepare some hooks for future usage (which incidentally are most of the ones I will need for my plugin 😄).

Last thing: when using multiple plugins it will be important to have a chance to configure the order in which their hooks will be called (which has just made me wondering if the "rev" file name hash should be evaluated after the bundle minification but i'm digressing)