[POC] Webpack front build

[m4dz]

This PR introduces Webpack for frontend build. It supports in this current configuration:

• build app JS and CSS files
• fast compilation
• all frontend deps from NPM
• static assets support
• code spliting for onboarding section
• optimization in production build mode
• watch mode for simplified development

Pros:

• efficient compilation
• clever piping system
• code spliting that produces chunks which are loaded dynamically when needed (in this case, onboarding code is split in a dedicated chunk which reduce the main codebase of ~25%)
• quick rebuild on watcher (still impressive)

Cons:

• webpack config file is verbose, even for a basic context
• it needs to understand webpack loaders and plugins concepts to really take advantages of the webpack pipeline system

My thoughs: even with their efforts, Brunch@2.x is still unstable with NPM deps, and sometimes make corrupted builds on watch mode. I didn't encounter this kind of issues with webpack (very fast and stable) and I think the final codebase is more robust (all deps declared, splitted code, etc). The config stay verbose, but can be easily deployed across our apps in a standard base config and can be customized after.

This PR is fully functionnal but serves as a POC for next ideations :smiley:.

[frankrousseau]

@m4dz Could you remove the build files? It makes the review hard to do.

[m4dz]

@frankrousseau I've suppressed the build removing from the PR. I'll open another PR for the clean (build and locales) as long as we don't push build and locales to other branches than master anymore.

[frankrousseau]

Thank you for removing the build. About the folder name change, I prefer we stick to our current convention. Including too many changes at the same time will create more chaos. Introducing webpack already brings enough changes.

[m4dz]

About static folder convention, Webpack will copy assets only if are referenced by a module (there's a "copy plugon" but it wll introduce mess in our files management if we mix in the same folder assets used by modules and those whose aren't). So, I think we'll need to keep those assets separately. We can continue to produce a client/public folder for hosting assets (instead of my static choice) but where can we keep assets not refercned (like favicons or fonts)? I suggest:

1. use a public folder at root that contain them (same as now, just rename static to public)
2. use a client/vendor folder from which all assets folder(s) will be copied directly to the build/public (a-la-brunch) (maybe using the copy plugin).

I think the 2. is a little bit more complicated but is the more reliable from our current use in _brunch_ed projects. @frankrousseau, any pref?

[frankrousseau]

I want to keep everything related to browser in the client folder. Subfolders can organized the way you want, but please keep the client and server separation.

Currently, I don't have much time to review the full thing. But from what I understand the second solution looks to follow our current convention. If that's the case, ok for it.

[aenario]

247 was merged, could you rebase this one ?

[m4dz]

Done!

[nono]

Looks good to me.

Before: 367K (87K for app.js + 280K for vendor.js) After: 244K for app.[hash].js

Nice size reduction. Thanks @m4dz!

[m4dz]

Nice size reduction

I also ask myself to enable compression using gzip in proxy server part, but as long as proxy serves all apps responses, it means enable it for all apps at one time. Should be ok, but I'll try it later in another PR to check if it's really good :smile:.