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
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
* Version v10.18.1
* Update changelog for v10.18.1
* Metrics adjustments (#15313)
* Don't send errors to sentry if users have not opted-in to participate in metametrics
* Don't capture opt-out metrics
* Move the metrics-opt in screen to immediately after the welcome screen
* Ensure that global.getSentryState is set in the background
* Fix e2e tests after rearranging onboardin flow
* Fix unit tests
* More e2e test fixes
* Remove unnecessary wrappers around capture exception
Co-authored-by: MetaMask Bot <metamaskbot@users.noreply.github.com>
Co-authored-by: Dan Miller <danjm.com@gmail.com>
* Updating design tokens v1.8 and shadows
* Adding missing stories
* Some fixes and updates to css and stories
* removing unneeded story
* Fixing story order
This reverts commit f09ab88891, reversing
changes made to effc761e0e.
This is being temporarily reverted to make it easier to release an
urgent fix for v10.15.1.
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
* Update xDAI E2E information
* Use local Ganache instance instead of Gnosis Chain
* Bump test-dapp
* Bump test-dapp
* Enable secondary Ganache server for other test
* Fix linting
* Improve E2E stability
* Update network selector
* Update xDAI E2E information
* Use local Ganache instance instead of Gnosis Chain
* Bump test-dapp
* Bump test-dapp
* Enable secondary Ganache server for other test
* Fix linting
* Improve E2E stability
* Update network selector
* Update xDAI E2E information
* Use local Ganache instance instead of Gnosis Chain
* Bump test-dapp
* Bump test-dapp
* Enable secondary Ganache server for other test
* Fix linting
* Improve E2E stability
* Update network selector
#14583 broke the development build scripts (e.g. `yarn start`) by adding a positional argument to a package script (`build:dev`) that is used and passed positional arguments in the build script itself. This PR removes the positional argument from the `build:dev` script and `yarn start` now works again. In addition, the `--apply-lavamoat` flag is properly forwarded to child processes, which was not the case in the original implementation.
To test, `yarn start` should work and LavaMoat should _not_ be applied, in distinction to `yarn build:dev dev --apply-lavamoat=true`. Whether LavaMoat is applied can be determined by checking whether `Object.isFrozen(Object.prototype)` is `true` (with LavaMoat) or `false` (without LavaMoat).
Adds a new flag, `--apply-lavamoat`, to the main build script. The flag controls whether LavaMoat is actually applied to the output of the build process. The flag defaults to `true`, but we explicitly set it to `false` in the `start` package script. Meanwhile, the `start:lavamoat` script is modified such that it applies LavaMoat to the build output in development mode, but it no longer runs the build process itself under LavaMoat as there aren't very compelling reasons to do so.
This change is motivated by the fact that development builds do not have their own dedicated LavaMoat policies, which causes development builds to fail since #14537. The downside of this change is that LavaMoat-related failures will not be detected when running `yarn start`. @kumavis has plans for fixing this problem in a future major version of the `@lavamoat` suite.
Alex Miller
Mark Stacey
Brad Decker
MetaMask Bot
Sam Gbafa
ryanml
Jyoti Puri
George Marshall
Frederik Bolding
Alex Donesky
PeterYinusa
Makoto Inoue
Erik Marks
Dan Miller
Daniel
kumavis