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.
Update `@metamask/controllers` from v6 to v8. The breaking changes were
all in controllers that aren't used by the extension, so no changes
were required.
Add changelog validation to CI, ensuring that the changelog follows the
KeepAChangelog format. Additionally, this will also ensure that all of
the auto-generated "Uncategorized" changelog entries on release
branches get categorized.
The `auto-changelog` script has been replaced with the package
`@metamask/auto-changelog`. This package includes a script that has
an `update` command that is roughly equivalent to the old
`auto-changelog.js` script, except better. The script also has a
`validate` command.
The `repository` field was added to `package.json` because it's
utilized by the `auto-changelog` script, and this was easier than
specifying the repository URL with a CLI argument.
* 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
The check for the GITHUB_TOKEN environment variable was being done in
the wrong release script. It has been migrated to the relevant script.
A second check for the username has also been added, as it is also
required.
