code bundling & optimization

[hxrts]

This touches on a few related topics:

• Config files, as described in this issue, would introduce tool-specific json files which specify permissions, source assets, and other tool data. For browser extensions, such information is typically declared in the root manifest.json file, which means we can either load everything and use namespace restriction or provide functions to do so dynamically, or we can statically compile a new manifest.json.
• Eventually we may be running several simultaneous frameworks, so we'll likely want to start integrating code optimization to deduplicate and exclude unnecessary code. The Google Closure Compiler is best in class here.
• A compile step might eventually hook into continuous integration and packaging of the chrome extension for the app store.

At first glance, Webpack seems like the best option if we're to go in this direction, but I'd like to consider any viable alternatives before making a commitment.

[hxrts]

see also chrome-extension-webpack-boilerplate

[g-a-v-i-n]

starting to look into this today, looks like it will introduce some big changes to how tools are added

[hxrts]

I'm really not wed to anything at this point. If you're up for it, I'd say give it a shot and we can adjust from there. Just getting a basic bundling step in place is a big step forward, even if it requires a fair amount of rearrangement. Feel free to delegate back to me if you'd prefer tho.

[hxrts]

hey @gavinpatkinson did you say you had something basic going? happy to tinker with this if you'd like to focus elsewhere.

[g-a-v-i-n]

I was messing around with this boilerplate chrome-extension-webpack-boilerplate, but didn't have time to port something over from the existing toolkit like we discussed. I think the port is worth it because everything is already sort of set up and working in the boilerplate so we'd have to do much less config hell

[hxrts]

All good. I'll give this a shot when I have a moment.