Now that Olm needs to be inited asynchronously anyway, we can just
pass the options to Olm.init(), and as long as we do that before we
start the js-sdk, we're all good.
This will means the olm js is now part of the main bundle but since
it's now just a wrapper around the wasm, this is probably faster.
Also add the directwatch flag to olm.wasm because otherwise it
doesn't seem to copy the file in watch mode...
Non-functional changes (before I start messing with it).
Switch to import, move code out of the top level, switch to one
consistent way of declaring functions, keep imports at the top.
+ conform to a bit more eslint (IDE makes my eyes hurt)
+ specify windows-specific copies of noParse regexes to stop the olm error
Signed-off-by: Michael Telatynski <7t3chguy@gmail.com>
Configure the dev server not to spew module lists all over the console.
(Arguably the fact our module list is so long that I have to do this is a bug,
but my life is too short)
Use postcss-webpack-loader instead of webpack-cli to process the scss. Doing so
mostly means that we avoid the problem that webpack-dev-server fails to start
if we haven't already built the CSS. (It also simplifies package.json somewhat,
which is no bad thing)
In order to better support a world where old build artifacts are available
(which is necessary to support bundle.js splitting), collect all the webpack
artifacts for the build into a single directory. Then we'll be able to clear
out old builds after a few weeks, knowing they won't be in use any more.
16M is somewhat excessive: configure olm to use a bit less.
Requires changes to the olm library to do anything useful, but will be harmless
without them.
Partial fix to vector-im/riot-web#2726.
Advantages:
* blocks while a rebuild is in progress so you're less likely to reload the
old version
* serves from memory rather than disk, so we no longer need to turn off the
cachebuster to avoid filling the disk with bundles. Empirically, seems to
last a plausible amount of time without OOMing; there's no real reason to
believe it would use any more memory than webpack itself.
* That in turn means we no longer need the hack to stop chrome caching old
sourcemaps (because the sourcemap now has a cachebuster in its name).
* one fewer process for parallelshell to (fail to) manage.
* in future, we could consider the fancy hot-reload functionality.
