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.
If olm isn't installed, webpack prints out scary warnings (though it still
actually succeeds). Let's avoid scaring people by quietly removing it from the
list of things to process.
This means that clients can do better caching of assets, as it will mean we are
no longer reliant on etags to ensure that clients get a fresh version.
We inhibit the cachebuster for `npm start`, so that we don't get millions of
copies of the bundles on dev boxes.
Fixes an error when matrix-js-sdk is symlinked into node_modules, which meant
that we would (try to) use the version of olm from js-sdk instead of
vector-web (https://github.com/vector-im/vector-web/issues/1765).
Since https://github.com/matrix-org/matrix-js-sdk/pull/141, the jenkins build
does pull in the olm module, but because it's using npm v2, buries it deep in
node_modules. Rather than using the `fs` module to hunt for it, just try to
`require` it in the webpack config.
* Make sure we only get one js-sdk (and update runtime config to match)
* Don't verifyNoOutstandingRequests (since it is hard to be certain which we
will get, and makes the tests too dependent on implementation-specifics).
* Disable color for npm test, to avoid confusing Jenkins
Hopefully, this fixes https://github.com/vector-im/vector-web/issues/1046
without any side-effects.
It relies on the fact that the languages files are pretty simple - in
particular, they don't require any other modules. So we can tell webpack just
to suck them in as they are, rather than parsing them and causing an explosm.
Webapck actually supports loading input source maps and generally seems a lot
more solid then browserify (even if their website has an annoying animated
logo).
Richard van der Hoff