This is the same system as the customisations override, however deliberately using a different JSON file to avoid conflicts.
Forks would be expected to use the customisations file, not the components file, to override/add components.
* Revert "Revert "Update minification and sourcemap settings on CI builds for sentry (#19583)" (#19601)"
This reverts commit 516e38c82d.
* Disable minification in CI as it exceeds memory limits for poor buildkite
With previous settings, our JS files for develop are so large that sentry's webserver rejects the upload.
* re-enable minification to reduce the size of the files
* update the CI sourcemap setting from eval-source-map to source-map to move the embedded source out of the .js payload and into .js.map files
Fixes https://github.com/vector-im/element-web/issues/19485
The variable should be set when it needs to by CI, but in every other environment it's not important. Simply setting it to *something* makes EnvironmentPlugin happy. We print a warning just in case people expect it to be set, and use a clear value in case the environment variable doesn't get properly set.
The key must match the theme name, otherwise the getThemesImports() function
will exit with an error.
Signed-off-by: Paulo Pinto <paulo.pinto@automattic.com>
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.
Michael Telatynski