Moving to loading via webpack

What does this MR do?

Adds webpack for managing frontend javascript.

Currently just Index and Dashboard modules are implemented in the new way, the others use the existing approach, so it's not too much to do in one go.

It means there are a few switches in the code now to do different things depending on whether it is webpack or not.

So, the process works like this now:

• new module-based javascript is in client/src
• (cd client && yarn && yarn build) will build a bunch of js and css files into assets/ directory in the root
• it also writes assets/modules.json which containers a map of the module (e.g. Modules/Dashboard) to a list of asset paths the frontend needs to load
• then the src/Modules/Core/Control.php will check this to see if the controller it is loading has an entry in there
• if so, then we are in webpack mode
• it will put links to the js files (and the js/jsFunc data) at the bottom of the page, and css files at the top of the page
• otherwise will try and do as it does currently

One of the challenges was how to deal with javascript that is not built by webpack, but used on the pages (e.g. in onclick handlers like <a onclick="foo()>, or in xhr responses). All the stuff inside the webpack environment is not available globally (as thats the whole point of it). To solve the above problem, I export some of it on the window object, as little as possible. This is in client/src/globals.js and it imports things from the webpack modules and adds them to the window object (which seems to be the real global window object).

Most of the files in client/src/ are just "modulralized" versions of the files in js/ - it uses standardjs linting which has nice support in Intellij, and lets us format it nicely, and keep track of undefined variables, etc. I have made only the most minimal fixes for now.

I also tried to get as many libraries as possible from npm now, but you still see the old ones under js/ as we keep compatability with the existing pages. We still load some of the libraries from there (see the aliases in client/shims.js).

The eventual goal is to delete js/ and client/shims.js.

How confident are you it won't break things if deployed?

I expect that I will have broken something. I'd like people to try and break it.

Links to related issues

Checklist

• added a test, or explain why one is not needed/possible... hmm, uses existing tests, not ready for unit testing js yet
• no unrelated changes mostly
• asked someone for a code review
• joined #foodsharing-beta channel at https://slackin.yunity.org
• added an entry to CHANGELOG.md (description, merge request link, username(s))