This PR fixes our local unit test package scripts. When the state migration unit tests were migrated to Jest in #12106, it left the `test:unit` script in a broken state, because it didn't tell `mocha` to ignore the state migration tests.
Arguably, that script was already broken, since the most reasonably expectation from its name is that it runs _all_ unit tests. The PR makes it so that it does just that, by means of `concurrently`.
Unfortunately, `concurrently` only outputs errors from child processes once (at the time when they exit, https://github.com/open-cli-tools/concurrently/issues/134). This means that we have to search/navigate the output for this combined script to identify the failure. That said, it's better than the status quo.
* lavamoat - add lavamoat to webapp background
* test:e2e - add delay to resolve failure
* test:e2e - add delay to resolve failure
* build - add a switch for applying lavamoat, currently off for all
* test/e2e - remove delays added for lavamoat
* Revert "test/e2e - remove delays added for lavamoat"
This reverts commit 79c3479f15c072ed362ba1d4f1af41ea11a17d63.
* lockdown - breakout making globalThis properties non-writable into lockdown-more.js
* Update app/scripts/lockdown-more.js
Co-authored-by: David Walsh <davidwalsh83@gmail.com>
* Update app/scripts/lockdown-more.js
Co-authored-by: Erik Marks <25517051+rekmarks@users.noreply.github.com>
Co-authored-by: David Walsh <davidwalsh83@gmail.com>
Co-authored-by: Erik Marks <25517051+rekmarks@users.noreply.github.com>
* Jestify migrations/
* Lint exclude migrations from mocha config, and add inclusion to jest config
* Add migration tests to jest config
* Exclude/ignore migration tests
* Set process.env.IN_TEST to true when running tests locally
Adds the latest version of `@metamask/controllers`, and updates our usage of the `ApprovalController`, which has been migrated to `BaseControllerV2`. Of [the new `controllers` release](https://github.com/MetaMask/controllers/releases/tag/v15.0.0), only the `ApprovalController` migration should be breaking.
This is the first time we use events on the `ControllerMessenger` to update the badge, so I turned the messenger into a property on the main `MetaMaskController` in order to subscribe to events on it in `background.js`. I confirmed that the badge does indeed update during local QA.
As it turns out, [MetaMask/controllers#571](https://github.com/MetaMask/controllers/pull/571) was breaking for a single unit test case, which is now handled during setup and teardown for the related test suite (`metamask-controller.test.js`).
* Replace hardcoded sent ether label on confirm screen
* replace transaction type SENT_ETHER with network agnostic SENDING_NATIVE_ASSET
* remove sentEther translation base
* make backwards compatible with lingering transaction of legacy sentEther type
* update localalization files
* fixup legacy sentEther transaction type
* changing new transaction type away from localization string
* revert migration tests
* update fixtures and test data
* update name of new transaction type
* add migration
* remove legacy SENT_ETHER from transaction types enum object
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>
* bump @metamask/controllers to v15.0.1 and remove AbortController workaround in e2e tests
* remove old abortcontroller polyfill
* bump @metamask/controllers to v15.0.2
There are a few issues encountered when running `yarn setup` on new
Apple Silicon (aka M1, aka arm64) Macs:
* The script halts when attempting to run the install step for
the `chromedriver` package with the message "Only Mac 64 bits
supported". This is somewhat misleading as it seems to indicate that
chromedriver can only be installed on a 64-bit Mac. However, what I
think is happening is that the installation script for `chromedriver`
is not able to detect that an arm64 CPU *is* a 64-bit CPU. After
looking through the `chromedriver` repo, it appears that 87.0.1 is the
first version that adds a proper check ([1]).
Note that upgrading chromedriver caused the Chrome-specific tests to
fail intermittently on CI. I was not able to 100% work out the reason
for this, but ensuring that X (which provides a way for Chrome to run
in a GUI setting from the command line) is available seems to fix
these issues.
* The script also halts when attempting to run the install step for
the `electron` package. This happens because for the version of
`electron` we are using (9.4.2), there is no available binary for
arm64. It appears that Electron 11.x was the first version to support
arm64 Macs ([2]). This is a bit trickier to resolve because we don't
explicitly rely on `electron` — that's brought in by `react-devtools`.
The first version of `react-devtools` that relies on `electron` 11.x
is 4.11.0 ([3]).
[1]: 469dd0a6ee
[2]: https://www.electronjs.org/blog/apple-silicon
[3]: https://github.com/facebook/react/blob/main/packages/react-devtools/CHANGELOG.md#4110-april-9-2021
There are a few issues encountered when running `yarn setup` on new
Apple Silicon (aka M1, aka arm64) Macs:
* The script halts when attempting to run the install step for
the `chromedriver` package with the message "Only Mac 64 bits
supported". This is somewhat misleading as it seems to indicate that
chromedriver can only be installed on a 64-bit Mac. However, what I
think is happening is that the installation script for `chromedriver`
is not able to detect that an arm64 CPU *is* a 64-bit CPU. After
looking through the `chromedriver` repo, it appears that 87.0.1 is the
first version that adds a proper check ([1]).
Note that upgrading chromedriver caused the Chrome-specific tests to
fail intermittently on CI. I was not able to 100% work out the reason
for this, but ensuring that X (which provides a way for Chrome to run
in a GUI setting from the command line) is available seems to fix
these issues.
* The script also halts when attempting to run the install step for
the `electron` package. This happens because for the version of
`electron` we are using (9.4.2), there is no available binary for
arm64. It appears that Electron 11.x was the first version to support
arm64 Macs ([2]). This is a bit trickier to resolve because we don't
explicitly rely on `electron` — that's brought in by `react-devtools`.
The first version of `react-devtools` that relies on `electron` 11.x
is 4.11.0 ([3]).
[1]: 469dd0a6ee
[2]: https://www.electronjs.org/blog/apple-silicon
[3]: https://github.com/facebook/react/blob/main/packages/react-devtools/CHANGELOG.md#4110-april-9-2021
Adds the latest version of `@metamask/controllers`, and updates our usage of the `ApprovalController`, which has been migrated to `BaseControllerV2`. Of [the new `controllers` release](https://github.com/MetaMask/controllers/releases/tag/v15.0.0), only the `ApprovalController` migration should be breaking.
This is the first time we use events on the `ControllerMessenger` to update the badge, so I turned the messenger into a property on the main `MetaMaskController` in order to subscribe to events on it in `background.js`. I confirmed that the badge does indeed update during local QA.
As it turns out, [MetaMask/controllers#571](https://github.com/MetaMask/controllers/pull/571) was breaking for a single unit test case, which is now handled during setup and teardown for the related test suite (`metamask-controller.test.js`).
This PR makes ~all named intrinsics in all of our JavaScript processes non-modifiable. A named intrinsic is any property specified by the ECMAScript specification that exists on `globalThis` when the JavaScript process starts. We say that a property is non-modifiable if it is non-configurable and non-writable. We make exceptions for properties that meet any of the following criteria:
1. Properties that are non-configurable by the time `lockdown-run.js` is executed are not modified, because they can't be.
2. Properties that have accessor properties (`get` or `set`) are made non-configurable, but their writability cannot be modified, and is therefore left unchanged. It's unclear how many of the named intrinsics this applies to, if any, but it's good defensive programming, regardless.
* Remove button group for non-EIP-1559 networks
* Fix tests...maybe
* Remove unnecessary props, as well as gas display
* Remove unused string
* test progress
* fix test
* fix test
* add customizes gas block to improve e2e pass rate
Co-authored-by: Alex <adonesky@gmail.com>
Fixing up tests and add back old custom gas modal for non-eip1559 compliant networks
Remove unnecessary props from send-gas-row.component
fix breaking test
Fix primary and secondary title overrides
fix rebase issue
Fix rebase conflict
Co-authored-by: David Walsh <davidwalsh83@gmail.com>
Niranjana Binoy
Mark Stacey
Erik Marks
kumavis
Jyoti Puri
Thomas Huang
PeterYinusa
Alex Donesky
Daniel
Elliot Winkler
David Walsh
Brad Decker
ryanml