This described in https://github.com/vector-im/element-web/issues/17330#issuecomment-842530812, this should prevent the newly introduced version of `html-webpack-plugin` from minifying `.html` files, like e.g. `index.html`, `jitsi.html`, et cetera …
Quoting @jryans via: https://github.com/vector-im/element-web/issues/17330#issuecomment-842415694
> The content of the `index.html` file is not a supported API surface, so it might change at any time.
>
> This document minification was not done on purpose, but instead it happened as a side effect of upgrading. We would happily accept a PR to fix this, but it is also not a priority for the core team.
Could please someone test and, hopefully, accept this change back to not minifying the `.html` files?
While it sounds like a useful warning at first, it turns out the warnings it
prints are ones we're unlike to ever act on, such as adding percentages and
pixels, which seem fine to have. This resets to default behaviour, which leaves
the warning off.
With the approach in https://github.com/vector-im/element-web/pull/16969,
Webpack seems to sometimes do what we want, sometimes not... I haven't quite
worked out why. Perhaps there's some conflict or race in Webpack's defaults...?
This new approach seems to work as expected when running
`./scripts/ci_package.sh`, which matches what development deployments are doing.
When running Nightly build we want to benefit from the fast runtime that React production offers and get rid of the runtime overhead that comes with development.
We are setting NODE_ENV and not "webpack.mode" to not loose sourcemaps and have minified sources in that environment
This adjusts our asset path handling to group KaTeX fonts in a more sensible way
alongside the other fonts we have. It also resolves production build issues on
Windows.
Fixes https://github.com/vector-im/element-web/issues/15911
We don't need to manually define `NODE_ENV` in the Webpack config, nor do we
need to set it outside Webpack with `cross-env` either, as Webpack's modes will
take care of this for us.
Effectively fixes https://github.com/vector-im/riot-web/issues/11074
Effectively fixes https://github.com/vector-im/riot-web/issues/7112
Fixes https://github.com/vector-im/riot-web/issues/6930
Fixes Jitsi widgets not working for guests (https://github.com/vector-im/riot-web/issues/8933)
Fixes https://github.com/vector-im/riot-web/issues/5048
Previously we were relying on an integration manager to be defined, functional, and alive in order to join Jitsi calls. This commit changes this so we aren't reliant on an integration manager for Jitsi calls at all, and gives people the option of choosing a Jitsi server via the config.json.
This side is just the wrapper/shell: the logic is mostly in the react-sdk (to be linked via PRs). This layer simply has an HTML file exported that can be used to render a Jitsi widget, and the react-sdk constructs a URL to access it locally. This is similar to how the mobile apps handle Jitsi widgets: instead of iframing the widget URL directly into the app, they pull apart the widget information and natively render it. We're effectively doing the same here by parsing the widget options and using our local wrapper instead of whatever happens to be defined in the widget state event.
Integration managers should still continue to offer a widget URL for Jitsi widgets as this is what the spec requires.
A large part of this is based upon Dimension's handling of Jitsi and widgets in general: a license has been granted to allow Riot (and therefore the react-sdk) to use the code and be inspired by it.
This changes Webpack to only output errors, warnings, or new compilations.
This has the effect of hiding the massive list of modules. The giant list was
actually _hiding_ warnings because they appear first and scroll off the
terminal.
Fixes https://github.com/vector-im/riot-web/issues/11864
This uses an environment variable because the build script assumes you want a production build, but we don't for this particular script. To avoid having a mess of NPM scripts to worry about, we'll just pass a flag down.
This moves the babel and postcss configs into the webpack config for ease of maintenance (and because we need variations of them). The typescript config is left outside the webpack config for IDEs to pick it up.
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.
