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.
The `auto-changelog.js` script crashes when trying to add a new release
header. This bug was introduced in #10847. The cause was a simple
misnamed parameter.
When updating the changelog for a release candidate, any unreleased
changes are now migrated to the release header.
Generally we don't make a habit of adding changes to the changelog
prior to creating a release candidate, but if any are there we
certainly don't want them duplicated.
The `auto-changelog.js` script has been refactoring into various
different modules. This was done in preparation for migrating this to
a separate repository, where it can be used in our libraries as well.
Functionally this should act _mostly_ the same way, but there have been
some changes. It was difficult to make this a pure refactor because of
the strategy used to validate the changelog and ensure each addition
remained valid. Instead of being updated in-place, the changelog is now
parsed upfront and stored as a "Changelog" instance, which is a new
class that was written to allow only valid changes. The new changelog
is then stringified and completely overwrites the old one.
The parsing had to be much more strict, as any unanticipated content
would otherwise be erased unintentionally. This script now also
normalizes the formatting of the changelog (though the individual
change descriptions are still unformatted).
The changelog stringification now accommodates non-linear releases as
well. For example, you can now release v1.0.1 *after* v2.0.0, and it
will be listed in chronological order while also correctly constructing
the `compare` URLs for each release.
The `verify-locale-strings.js` script now validates that the
descriptions from the `en` locale are also present in all other
locales.
These descriptions are intended to help with translation, and are not
meant to be translated. This check will ensure that translators don't
accidentally translate these. It also ensures they're present alongside
each translated message, which might be helpful for understanding
context.
The report on missing messages has been removed from the verify
locales script. This report was making the console output of this
command unreasonably long, and would obscure the reports on any invalid
entries.
A new script was written to report on missing localized messages.
This can be run with the command `yarn locale-coverage`. This will
print a report to the console on the coverage for each locale.
This mock Segment server can be used to test our extension metrics. It
will respond to all request with HTTP 200, and will print the requests
to the console. It also has parsing built-in for Segment request
payloads.
Right now only the event name is printed, but we can enhance this in
the future to print more event information. We can also enhance the
mock to be a more realistic representation of the API.
The extension has been modified to allow the Segment host to be
overwritten with the `SEGMENT_HOST` environment variable. This will
ensure that all Segment events are redirected to that host.
So for example, to create a dev build that uses this server, you could
set the `SEGMENT_WRITE_KEY` and `SEGMENT_LEGACY_WRITE_KEY` values to
any non-empty string, and set `SEGMENT_HOST` to
`http://localhost:9090`.
This was created originally to test PR #9768
