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
* Update contract address validations in swaps for different networks
* Add support for direct contract swaps for wrapping and unwrapping
* Add WETH_RINKEBY_CONTRACT_ADDRESS
1. Display the new address detected dialog if the contract is not in the address book
2. Use the address book if exists, else use the default.
Signed-off-by: Akintayo A. Olusegun <akintayo.segun@gmail.com>
* Sort contacts alphabetically
Contacts are grouped together by letter, and the groups are listed
alphabetically, but the contacts in each group are not sorted
alphabetically themselves.
Fixes#10318.
* Improve tests to be less brittle
* Remove this matcher
* Revert this file
* Also don't need this change anymore
* Don't need this data attribute either
* 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
This PR updates our minimum supported Chrome version from 63 to 66, so that we may use the `AbortController` browser API without polyfilling it.
Our minimum Firefox version supports the `AbortController`, but our current minimum Chrome version (63, released in December 2017) does not. Chrome shipped the `AbortController` in version 66, in April 2018. We have determined that an extremely small number of users are on Chrome 63 < 66, and that this change is therefore acceptable.
