* Create `.zip` files deterministically
Our build system now creates `.zip` archives deterministically.
Previously the `.zip` file would differ between builds even when the
files being archived were identical. This was because the order the
files were passed in was non-deterministic, and the `mtime` for each
file was different between builds.
The files are now sorted before being zipped, and the `mtime` for each
file has been set to the unix epoch.
* Update lavamoat build policy
#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.
* Rename NotificationController to AnnouncementController
* Fix test
* Add test for missing NotificationController state
* Bump controllers
* Move test to correct file
* Rename config key
* Add migration 71 to list of migrations
* Fix selector after migration
We currently store the JSON-RPC request and response objects in the permission activity log. The utility of doing this was always rather dubious, but never problematic. Until now.
In Flask, as the restricted methods have expanded in number, user secrets may be included on JSON-RPC message objects. This PR removes these properties from the permission activity log, and adds a migration which does the same to existing log objects. We don't interact with the log objects anywhere in our codebase, but we don't want unexpected properties to cause errors in the future should any log objects be retained.
This PR also updates relevant tests and test data. It makes a minor functional change to how a request is designated as a success or failure, but this should not change any behavior in practice.
This commit modifies the build system so that TypeScript files can be
transpiled into ES5 just like JavaScript files.
Note that this commit does NOT change the build system to run TypeScript
files through the TypeScript compiler. In other words, no files will be
type-checked at the build stage, as we expect type-checking to be
handled elsewhere (live, via your editor integration with `tsserver`,
and before a PR is merged, via `yarn lint`). Rather, we merely instruct
Babel to strip TypeScript-specific syntax from any files that have it,
as if those files had been written using JavaScript syntax alone.
Why take this approach? Because it prevents the build process from being
negatively impacted with respect to performance (as TypeScript takes a
significant amount of time to run).
It's worth noting the downside of this approach: because we aren't
running files through TypeScript, but relying on Babel's [TypeScript
transform][1] to identify TypeScript syntax, this transform has to keep
up with any syntax changes that TypeScript adds in the future. In fact
there are a few syntactical forms that Babel already does not recognize.
These forms are rare or are deprecated by TypeScript, so I don't
consider them to be a blocker, but it's worth noting just in case it
comes up later. Also, any settings we place in `tsconfig.json` will be
completely ignored by Babel. Again, this isn't a blocker because there
are some analogs for the most important settings reflected in the
options we can pass to the transform. These and other caveats are
detailed in the [documentation for the transform][2].
[1]: https://babeljs.io/docs/en/babel-plugin-transform-typescript
[2]: https://babeljs.io/docs/en/babel-plugin-transform-typescript#caveats
There were several issues related to a retry mechanism. The latest keyring
offers a significant speed and UX enhancement relative to the previous release.
For full details, see:
GridPlus/eth-lattice-keyring@v0.5.0...v0.6.1
There were several issues related to a retry mechanism. The latest keyring
offers a significant speed and UX enhancement relative to the previous release.
For full details, see:
GridPlus/eth-lattice-keyring@v0.5.0...v0.6.1
* Changed registryUrl for snaps only in firefox
Fixed getPlatform to only be imported into metamask-controller in flask
Removed snaps specific testrunner script and use run-all with a cli option
* Fixed flakey tests
* Removed unneeded await
* Added delay
* Fixed linting
The Yarn resolution for `node-forge` has been updated to use a more
recent version of the library that includes fixes for the
vulnerabilities currently causing our audit job to fail. This update
should include no breaking changes.
The Yarn resolution for `node-forge` has been updated to use a more
recent version of the library that includes fixes for the
vulnerabilities currently causing our audit job to fail. This update
should include no breaking changes.
The library `@testing-library/user-event` has been updated to the
latest beta version, so that our unit tests better model real user
interactions. In particular, I found that previously the `paste` event
was missing the `clipboardData` API, so it was impossible to implement
any custom handling of paste events (which we will need in later PRs).
See the `v14.0.0-beta.1` release notes for a list of all breaking
changes [1]. The main change is that all methods now return Promises.
The `paste` method has also been dramatically simplified.
The unit tests have also been updated to reset all mocks before each
test. These tests don't have any shared mocks, but this is generally a
good practice, to ensure that tests don't develop accidental inter-
dependencies.
[1]: https://github.com/testing-library/user-event/releases/tag/v14.0.0-beta.1
This is a pure refactor that extracts the SRP input from the
`CreateNewVault` component. This is intended to make future changes to
the SRP input easier, and to reduce duplication between the old and new
onboarding flows.
Extensive unit tests have been added for the new SRP input component.
A new test library was added (`@testing-library/user-event`) for
simulating user events with components rendered using the
`@testing-library` library.
A new helper method has been added (`renderWithLocalization`) for
rendering components using `@testing-library` with just our
localization contexts added as a wrapper. The localization contexts
were already added by the `renderWithProviders` helper function, but
there is no need for a Redux provider in these unit tests.
kumavis
Alex Miller
Frederik Bolding
Mark Stacey
PeterYinusa
Brad Decker
Erik Marks
Shane
MetaMask Bot
ryanml
Daniel
David Walsh
George Marshall
Elliot Winkler
Erik Marks