* Removing support notification from what's new
* Adding migration for support notification removal
* Expanding test cases, using async/await for storage comparison
Sentry is now configured with environment variables, rather than with
hard-coded values. This makes it easier to test Sentry functionality
using a different Sentry account, as we did recently during QA of
v9.5.1.
The only change for the normal build process is the introduction of the
`SENTRY_DSN_DEV` variable, which can be set via `.metamaskrc` or via an
environment variable. This determines where error reports are sent. It
still defaults to our team Sentry account's `metamask-testing` project.
The `sentry:publish` script now requires SENTRY_ORG and SENTRY_PROJECT
to be set in order to publish release artifacts. The CircleCI
configuration has been updated with these values, so it should act the
same as it did before. Previously we had used a CLI flag to specify the
organization and project, but Sentry already natively supports these
environment variables [1].
[1]: https://docs.sentry.io/product/cli/configuration/#configuration-values
* Add a notification for BSC Swaps
* Add a new logo for BSC sources, update an image for BSC notification
* Mark a BSC notification as seen when a user clicks on “Start swapping”
* Add conditional rendering of notifications
* Remove divider for the last notification
* Remove a divider for the last notification
* Remove !
* Trigger pipeline
Three uses of `hasOwnProperty.call` have been replaced with simpler
alternatives. I did this because I found this convention confusing.
The `ComposableObservableStore` changes required adding a check for
whether the `config` is defined, because the old syntax would allow
iterating over `undefined` as if it was an empty object. Functionally
it should be identical. A new test was added to highlight this
functionality.
The version field is now stored in the main `package.json` file rather
than in the base manifest. It is built into the final manifest during
the build script.
This makes it easier to communicate what the current version should be
to our `auto-changelog` script. It's also generally a more conventional
place to keep track of the version, even considering that we're not
publishing to npm.
The `assert` module has two modes: "Legacy" and "strict". When using
strict mode, the "strict" version of each assertion method is implied.
Whereas in legacy mode, by default it will use the deprecated, "loose"
version of each assertion.
We now use strict mode everywhere. A few tests required updates where
they were asserting the wrong thing, and it was passing beforehand due
to the loose matching.
The `SET_CURRENT_FIAT` action has been removed. It has been replaced
by a call to `forceUpdateMetamaskState`. The only purpose of this
action was to eagerly update the current fiat currency settings before
the next state update. Forcing a state update instead is simpler and
safer.
The `setCurrentCurrency` function in the background has been updated to
no longer return the state, now that it's no longer needed.
* Allow 0% slippage, show a warning for 0 < slippage <= 1, disable “Review Swap” button for negative slippage
* Update a translation key, use both new and old key until it’s translated everywhere
* Keep an old key for `en`: swapSlippageTooLow
* Fix an ESLint issue
* Only use swapSlippageNegative, remove swapSlippageTooLow
* Add stringified payload to metametrics controller trackEvent error message
* Don't include full payload when throwing error on missing event or category in trackEvent
