This corrects our path handling on Windows development machines for
paths referenced in JS and HTML files. Both images and fonts (like
Twemoji) were afflicted (with Windows-style backslash path delimiters),
but browsers seems to tolerate them in the `src` attribute of images, so
we didn't notice that variant before.
Most `npm` operations are replaced with `yarn`, which generally has better
behavior. However, steps like publish that write to the NPM registry are left to
`npm`, which currently handles these tasks best.
This change causes Node to crash during builds in some configurations. It also
grows the production bundle size to ~4x what it was before.
This reverts commit 9f4ce2dcf2.
The path adjustment for assets in bundles is only needed with CSS files. Paths
referenced in JS files are written to elements, where they are relative to the
document.
This adds a `file-loader` rule to the Webpack build so that any requests for
image resource will be output into the app's output directory, but with an extra
content has appended so that we can safely use a long cache lifetime.
The CSS and SCSS rules are also changed to use `css-loader` so that any `url`
inside is automatically processed by the new image rule above.
* Turn off node integration in the electron renderer process
* Enable the chromium sandbox to put the renderer into its own process
* Expose just the ipc module with a preload script
* Introduce a little IPC call wrapper so we can call into the
renderer process and await on the result.
* Use this in a bunch of places we previously used direct calls
to electron modules.
* Convert other uses of node, eg. use of process to derive the
platform (just look at the user agent)
* Strip out the desktopCapturer integration which doesn't appear
to have ever worked (probably best to just wait until
getDisplayMedia() is available in chrome at this point:
https://github.com/vector-im/riot-web/issues/4880).
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.
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).
J. Ryan Stinnett