* Version v10.18.4
* Fix default currency symbol for `wallet_addEthereumChain` + improve warnings for data that doesn't match our validation expectations (#15201)
* set more appropriate default for ticker symbol when wallet_addEthereumChain is called
* throw error to dapp when site suggests network with same chainId but different ticker symbol from already added network, instead of showing error and disabled notification to user
* Fix Provider Tracking Metrics (#15082)
* fix filetype audit (#15334)
* Remove decentralized 4byte function signature registry since it contains incorrect signatures and we can't algorithmically check for best option when 4byte.directory is down (#15300)
* remove decentralized 4byte function signature registry since it is griefed and we can't algorithmically check for best option when 4byte is down
* add migration
* remove nock of on chain registry call in getMethodDataAsync test
* remove audit exclusion (#15346)
* Updates `eth-lattice-keyring` to v0.10.0 (#15261)
This is mainly associated with an update in GridPlus SDK and enables
better strategies for fetching calldata decoder data.
`eth-lattice-keyring` changes:
GridPlus/eth-lattice-keyring@v0.7.3...v0.10.0
`gridplus-sdk` changes (which includes a codebase rewrite):
GridPlus/gridplus-sdk@v1.2.3...v2.2.2
* Fix 'block link explorer on custom networks' (#13870)
* Created a logic for the 'Add a block explorer URL'
Removed unused message
Message logic rollback
Modified history push operation
WIP: Pushing before rebasing
Applied requested changes
Removed unintenionally added code
* Lint fix
* Metrics fixed
* Stop injecting provider on docs.google.com (#15459)
* Fix setting of gasPrice when on non-eip 1559 networks (#15628)
* Fix setting of gasPrice when on non-eip 1559 networks
* Fix unit tests
* Fix logic
* Update ui/ducks/send/send.test.js
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
* [GridPlus] Bumps `eth-lattice-keyring` to v0.11.0 (#15490)
* [GridPlus] Bumps `gridplus-sdk` to v2.2.4 (#15561)
* remove exclusions for mismatched object jsdoc type casing (#15351)
* Improve `tokenId` parsing and clean up `useAssetDetails` hook (#15304)
* Fix state creation in setupSentryGetStateGlobal (#15635)
* filter breadcrumbs for improved clarity while debugging sentry errors (#15639)
* Update v10.18.4 changelog (#15645)
* Auto generated changelog
* Update 10.18.4 changelog
* Run lavamoat:auto
* Call metrics event for wallet type selection at the right time (#15591)
* Fix Sentry in LavaMoat contexts (#15672)
Our Sentry setup relies upon application state, but it wasn't able to
access it in LavaMoat builds because it's running in a separate
Compartment.
A patch has been introduced to the LavaMoat runtime to allow the root
Compartment to mutate the `rootGlobals` object, which is accessible
from outside the compartment as well. This lets us expose application
state to our Sentry integration.
* Fix Sentry deduplication of events that were never sent (#15677)
The Sentry `Dedupe` integration has been filtering out our events, even
when they were never sent due to our `beforeSend` handler. It was
wrongly identifying them as duplicates because it has no knowledge of
`beforeSend` or whether they were actually sent or not.
To resolve this, the filtering we were doing in `beforeSend` has been
moved to a Sentry integration. This integration is installed ahead of
the `Dedupe` integration, so `Dedupe` should never find out about any
events that we filter out, and thus will never consider them as sent
when they were not.
* Replace `lavamoat-runtime.js` patch (#15682)
A patch made in #15672 was found to be unnecessary. Instead of setting
a `rootGlobals` object upon construction of the root compartment, we
are now creating a `sentryHooks` object in the initial top-level
compartment. I hadn't realized at the time that the root compartment
would inherit all properties of the initial compartment `globalThis`.
This accomplishes the same goals as #15672 except without needing a
patch.
* Update v10.18.4 changelog
* Fix lint issues
* Update yarn.lock
* Update `depcheck` to latest version (#15690)
`depcheck` has been updated to the latest version. This version pins
`@babel/parser` to v7.16.4 because of unresolved bugs in v7.16.5 that
result in `depcheck` failing to parse TypeScript files correctly.
We had a Yarn resolution in place to ensure `@babel/parser@7.16.4` was
being used already. That resolution is no longer needed so it has been
removed. This should resove the issue the dev team has been seeing
lately where `yarn` and `yarn-deduplicate` disagree about the state the
lockfile should be in.
* Update yarn.lock
* Update LavaMoat policy
* deduplicate
* Update LavaMoat build policy
Co-authored-by: MetaMask Bot <metamaskbot@users.noreply.github.com>
Co-authored-by: Alex Donesky <adonesky@gmail.com>
Co-authored-by: Brad Decker <bhdecker84@gmail.com>
Co-authored-by: Alex Miller <asmiller1989@gmail.com>
Co-authored-by: Filip Sekulic <filip.sekulic@consensys.net>
Co-authored-by: Erik Marks <25517051+rekmarks@users.noreply.github.com>
Co-authored-by: Dan J Miller <danjm.com@gmail.com>
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
Co-authored-by: seaona <54408225+seaona@users.noreply.github.com>
Co-authored-by: seaona <mariona@gmx.es>
Co-authored-by: PeterYinusa <peter.yinusa@consensys.net>
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
The version of a build is now derived from both the `version` field in
`package.json` and the requested build type and version. The build type
and version are added onto the manifest version as a suffix, according
to the SemVer prerelease format.
We already have support in the extension for versions of this format,
but to apply a Flask or Beta version required manual updates to
`package.json`. Now it can be done just with build arguments.
A `get-version` module was created to make it easier to generate the
version in the various places we do that during the build. It was
created in the `development/lib` directory because it will be used by
other non-build development scripts in a future PR.
The `BuildType` constant was extracted to its own module as well, and
moved to the `development/lib` directory. This was to make it clear
that it's used by various different development scripts, not just the
build.
The version of a build is now derived from both the `version` field in
`package.json` and the requested build type and version. The build type
and version are added onto the manifest version as a suffix, according
to the SemVer prerelease format.
We already have support in the extension for versions of this format,
but to apply a Flask or Beta version required manual updates to
`package.json`. Now it can be done just with build arguments.
A `get-version` module was created to make it easier to generate the
version in the various places we do that during the build. It was
created in the `development/lib` directory because it will be used by
other non-build development scripts in a future PR.
The `BuildType` constant was extracted to its own module as well, and
moved to the `development/lib` directory. This was to make it clear
that it's used by various different development scripts, not just the
build.
ESLint rules have been added to enforce our JSDoc conventions. These
rules were introduced by updating `@metamask/eslint-config` to v9.
Some of the rules have been disabled because the effort to fix all lint
errors was too high. It might be easiest to enable these rules one
directory at a time, or one rule at a time.
Most of the changes in this PR were a result of running
`yarn lint:fix`. There were a handful of manual changes that seemed
obvious and simple to make. Anything beyond that and the rule was left
disabled.
The Firefox extension version format does not support the version
format we use (SemVer), so we have to specially format the extension
version to be compatible. The format we chose was
`[major].[minor].[patch].[buildType][buildVersion]`. But when we tried
to submit a build with a version in that format, it was rejected as
invalid for unknown reasons.
The Firefox extension format has been updated to
`[major].[minor].[patch][buildType][buildVersion]`. This seems to pass
validation.
The `version_name` manifest field was being used on Chrome to store the
build type. However, Chrome intended this field to be a full
representation of the version, for display purposes. This was evident
when uploading this version to the Chrome Web Store, because it used
`flask` as the entire version.
Instead the `version_name` field now includes the full SemVer version
string. The version parsing code within the build script and in the
wallet itself have been updated accordingly.
The build script only allowed prerelease versions for the "beta" build
type (e.g. `X.Y.Z-beta.0`). Now it allows Flask prerelease versions as
well.
This is required for the Flask release, where the prerelease version
helps distinguish the Flask error reports and metrics.
The build type (i.e. the distribution) is now included in the Sentry
environment during setup, for all builds except the "main" build. This
will allow us to track Flask and beta errors separately from other
errors.
A constant was created for the build types. The equivalent constant in
our build scripts was updated to match it more closely, for
consistency. We can't use the same constant in both places because our
shared constants are in modules that use ES6 exports, and our build
script does not yet support ES6 exports.
The singular `BuildType` was used rather than `BuildTypes` to match our
naming conventions elsewhere for enums. We name them like classes or
types, rather than like a collection.
Relates to #11896
The main `version` field in `package.json` will now include the beta
version (if present) rather than it being passed in via the CLI when
building. The `version` field is now a fully SemVer-compatible version,
with the added restriction that any prerelease portion of the version
must match the format `<build type>.<build version>`.
This brings the build in-line with the future release process we will
be using for the beta version. The plan is for each future release to
enter a "beta phase" where the version would get updated to reflect
that it's a beta, and we would increment this beta version over time as
we update the beta. The manifest gives us a place to store this beta
version. It was also important to replace the automatic minor bump
logic that was being used previously, because the version in beta might
not be a minor bump.
Additionally, the filename logic used for beta builds was updated to
be generic across all build types rather than beta-specific. This will
be useful for Flask builds in the future.
This PR adds build-time code exclusion by means of code fencing. For details, please see the README in `./development/build/transforms`. Note that linting of transformed files as a form of validation is added in a follow-up, #12075.
Hopefully exhaustive tests are added to ensure that the transform works according to its specification. Since these tests are Node-only, they required their own Jest config. The recommended way to work with multiple Jest configs is using the `projects` field in the Jest config, however [that feature breaks coverage collection](https://github.com/facebook/jest/issues/9628). That being the case, I had to set up two separate Jest configs. In order to get both test suites to run in parallel, Jest is now invoked via a script, `./test/run-jest.sh`.
By way of example, this build system feature allows us to add fences like this:
```javascript
this.store.updateStructure({
...,
GasFeeController: this.gasFeeController,
TokenListController: this.tokenListController,
///: BEGIN:ONLY_INCLUDE_IN(beta)
PluginController: this.pluginController,
///: END:ONLY_INCLUDE_IN
});
```
Which at build time are transformed to the following if the build type is not `beta`:
```javascript
this.store.updateStructure({
...,
GasFeeController: this.gasFeeController,
TokenListController: this.tokenListController,
});
```
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
This rationalizes how arguments are passed to and parsed by the build system. To accomplish this, everything that isn't an environment variable from `.metamaskrc` or our CI environment is now passed as an argument on the command line.
Of such arguments, the `entryTask` is still expected as a positional argument in the first position (i.e. `process.argv[2]`), but everything else must be passed as a named argument. We use `minimist` to parse the arguments, and set defaults to preserve existing behavior.
Arguments are parsed in a new function, `parseArgv`, in `development/build/index.js`. They are assigned to environment variables where convenient, and otherwise returned from `parseArgv` to be passed to other functions invoked in the same file.
This change is motivated by our previous inconsistent handling of arguments to the build system, which will grow increasingly problematic as the build system grows in complexity. (Which it will very shortly, as we introduce Flask builds.)
Miscellaneous changes:
- Adds a build system readme at `development/build/README.md`
- Removes the `beta` package script. Now, we can instead call: `yarn dist --build-type beta`
- Fixes the casing of some log messages and reorders some parameters in the build system
MetaMask Bot
Mark Stacey
Brad Decker
Erik Marks
David Walsh