Support has been restored for Chromium v78. Previously the extension
would crash upon startup.
The main incompatibility was the use of ES2020 operators (the optional
chain and nullish coalesce operators) in the libraries
`@ethereumjs/util` and `superstruct`. This was resolved by transpiling
those libraries.
After fixing that, the extension no longer crashed but the UI refused
to connect. This was because the UI process was not being identified as
an internal process, because the code responsible for checking that was
relying on the `origin` property of `MessageSender` [1] which wasn't
added until Chromium v80. The check has been updated to use the `url`
property instead, which existed in older versions of Chrome.
Lastly, the content security policy was updated to include the default
content security policy alongside the intended modification. Newer
versions of Chrome will merge the configired CSP with the default, but
older versions required it to be explicitly specified. This should not
result in any functional change.
[1]: https://developer.chrome.com/docs/extensions/reference/runtime/#type-MessageSender
The `brave` and `opera` builds are obsolete; in practice we have been
using the Chrome build for those browsers, because they are based upon
Chromium and are compatible with the Chrome extension API.
We now use the `latest` tag for the phishing warning page, we now use
the version that matches what we have in our manifest. This ensures
that our phishing warning e2e tests match the behaviour of the
production build, and it ensures that breaking changes to the phishing
warning page don't impact users in production.
Environment variables are now considered as higher-precedence than
configuration by our build system. This means that if the same value is
set in `.metamaskrc` and in an environment variable, the environment
variable is what will be used. Previously the reverse was true, the
configuration would take precedence.
It is conventional for CLI tools to consider environment variables as
higher precedence than configuration. This makes our build system less
surprising for most people.
The portfolio URL added in #15407 was meant to be configurable via
environment variable or the `.metamaskrc` file, but that configuration
was broken. Instead the default value was always used.
That configuration has been fixed. The portfolio URL can be set either
by environment variable or configuration file.
Validation has been added to the build script when the "prod" target is
selected. We now ensure that all expected environment variables are
set, and that no extra environment variables are present (which might
indicate that the wrong configuration file is being used).
The `prod` target uses a new `.metamaskprodrc` configuration file. Each
required variable can be specified either via environment variable or
via this config file. CI will continue set these via environment
variable, but for local manual builds we can use the config file to
simplify the build process and ensure consistency.
A new "dist" target has been added to preserve the ability to build a
"production-like" build without this validation.
The config validation is invoked early in the script, in the CLI
argument parsing step, so that it would fail more quickly. Otherwise
we'd have to wait a few minutes longer for the validation to run.
This required some refactoring, moving functions to the utility module
and moving the config to a dedicated module.
Additionally, support has been added for all environment variables to
be set via the config file. Previously the values `PUBNUB_PUB_KEY`,
`PUBNUB_SUB_KEY`, `SENTRY_DSN`, and `SWAPS_USE_DEV_APIS` could only be
set via environment variable. Now, all of these variables can be set
either way.
Closes#15003
There is a SES bug that results in errors being printed to the console
as `{}`[1]. The known workaround is to print the error stack rather
than printing the error directly. This affects our build script when it
is run with LavaMoat.
We used this workaround in one place in the build script already, but
not in the handler for task errors. We now use it in both places.
The workaround has been moved to a function that we can use throughout
the build script.
[1]: https://github.com/endojs/endo/issues/944
We use the `rc` package to read the `.metamaskrc` configuration file,
which is in "ini" format. This package has been replaced by the `ini`
package.
The `rc` package was not actively maintained, and it has had recent
security vulnerabilities. But most importantly, the config object
returned by `rc` includes a bunch of extra information that made build
script validation [1] difficult to implement. Specifically, it made it
challenging to ensure no extra environment variables were present.
The `ini` package on the other hand is simple, well maintained, and
is simpler to use. This package doesn't add any extra properties to the
object it returns, making validation easy.
[1]: https://github.com/MetaMask/metamask-extension/issues/15003
The "scripts" portion of the build script has been refactored to pass
the "build target" throughout the file. The "build target" is the
target environment for the build, reflected by the command used to
start the build (e.g. "dev", "prod", "test", or "testDev").
Beforehand we derived the variables `devMode` and `testing` from this
build target, and passed these throughout the script. However, there is
a future change [1] that requires adding a new build target that acts
like "prod" in some ways but not others. It was easier to refactor to
pass through `buildTarget` directly than it was to add a _third_
boolean flag to indirectly represent the target.
The existence of the "testDev" target made it convenient to still have
the `testing` and `devMode` flag, so helper functions were added to
derive those values from the build target. I anticipate that these will
only be needed temporarily though. We will probably be able to get rid
of the `testDev` target and the related complexities when we start
adding more flags (like `--watch`[2] and `--minify`[3]) to the build
script directly.
[1]: https://github.com/MetaMask/metamask-extension/issues/15003
[2]: https://github.com/MetaMask/metamask-extension/issues/12767
[3]: https://github.com/MetaMask/metamask-extension/issues/12768
* Fix "app-init" injection
The way we were injecting variables into the `app-init.js` bundle was
accidentally overwriting the bundle output with the raw `app-init.js`
source file. This is a problem because the bundling process handles a
lot of things we care about like source maps, polyfills and other
necessary Babel transformations, environment variable injection, and
minification.
Instead of using string replacement to inject variables, we are now
using environment variables. The old string replacement strategy has
been removed, and the `app-init.js` module is now generated using the
same process as our other bundles.
A new option, "extraEnvironmentVariables", was added to allow us to
inject environment variables specifically for this bundle.
* Add check to ensure APPLY_LAVAMOAT is set
This is a follow-up to #15318, which fixed a problem with environment
variables. Every function in this module that passes options related to
environment variables has been updated with a doc comment. This should
make it clearer which options are mandatory and which are optional,
hopefully preventing a similar mistake from happening in the future.
The environment variables `IN_TEST` and `METAMASK_DEBUG` were not
being set to `false` correctly. Instead those variables were being
skipped, and were resolved to `undefined` at runtime. This is confusing
because the other environment variables do not work that way - they can
be set to false.
The build script has been updated to ensure those two environment
variables are always set to `true` or `false` - never `undefined`.
Additionally, the `METAMASK_VERSION` environment variable was being
omitted from the `app-init.js` bundle. For the sake of consistency,
that has also been restored.
Some of the functions in `development/build/scripts.js` have been
renamed to better describe their function, and to be more consistent
with other similar functions.
Two unused options have been removed from the `createNormalBundle`
function in the build script: 'extraEntries` and `modulesToExpose`.'
Both of these options were used in the old "main" bundles, before we
began using the "factored" bundles. They have been unused since #11080.
Currently the build .zip has its time set to the Unix epoch, which
apparently causes problems on certain operating systems when in a
timezone that is behind GMT.
The build timestamp has been changed to MetaMask's birthday. Time
zone adjustments will no longer result in invalid dates.
The build script now uses `yargs` rather than `minimist`. The CLI is
now better documented, and we have additional validation for each
option.
A patch for `yargs` was required because it would blow up on the line
`Error.captureStackTrace`. For some reason when running under LavaMoat,
that property did not exist.
Closes#12766
