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 changelog script now accepts an `--rc` flag to tell it whether to
add new changes to `Unreleased` or to the header for the current
version.
Previously this was inferred from whether the current version matched
the most recent tag. However this method only works for the first
update. Using a flag simplifies this logic, and makes it possible to
manually re-run this for further updates to a release candidate.
Each changelog release now has category headers. The standard "keep a
changelog" [1] categories are used, along with the addition of
"Uncategorized" for any changes that have not yet been categorized.
The changelog script has been updated to add this "Uncategorized"
header if it isn't already present, and to place any new commits under
this header.
The changelog has been updated to property categorize each change in
recent releases, and to place changes in older releases under the
header "Uncategorized".
[1]: https://keepachangelog.com/en/1.0.0/
Each release header now includes a link to the range of commits
included with that release. These links are at the end of the document,
in accordance with the "keep a changelog" [1] format.
For the purpose of this changelog, the "previous release" is the most
recent release mentioned in the changelogs. The diffs ignore any
releases that were omitted from the changelog. This is mainly an issue
with older releases, so it seemed acceptable. All releases have been
documented for a couple of years now, and will be going forward as
well.
The name of the "Current Develop Branch" section was changed to
"Unreleased" to confirm with "keep a changelog".
The `auto-changelog.js` script has been updated to update/add these
links whenever adding a new release header as well.
[1]: https://keepachangelog.com/en/1.0.0/
The changelog release header format has been updated to match the "keep
a changelog" [1] format. Each header is now the bracketed version
number followed by a dash, then the release date in ISO-8601 format.
The release dates in each header were also updated to match the date of
the corresponding GitHub Release [2]. Many of these dates were
incorrect because they were set on the day we created the release
candidate, rather than on the day of release.
Any changelog release entries without a corresponding GitHub release
was left with the date already specified.
The three oldest release headers were missing dates. For the first two,
I used the date of the version bump commit. For the third, I removed it
since no changes were listed anyway, and it represented a range of
releases rather than a single one.
The `auto-changelog.js` script has been updated to account for this new
format as well.
[1]: https://keepachangelog.com/en/1.0.0/
[2]: https://github.com/MetaMask/metamask-extension/releases
The changelog update script now prevents duplicate entries from being
added. Specifically, it will ensure that if a PR has been referenced
already in an entry, it will not add it again.
This should prevent it from adding duplicate entries for changes that
were cherry-picked into hotfix releases.
Note that this duplication prevention only works for entries containing
a PR number. We don't have any way to prevent duplicate entries yet in
cases where we don't know the associated PR. We will be preventing this
possibility entirely pretty soon in some upcoming release automation
changes though, so I'm not concerned about this omission.
Instead of always placing new changelog entries under the "Current
Develop Branch" header, the changelog script now places them under the
header for the current release if that release has not yet been tagged.
This eliminates one manual step from the release process.
Relates to #10752
Our build script waits for the `close` event to determine whether the
task has exited. The `exit` event is a better representation of this,
because if a stream is shared between multiple processes, the process
may exit without the `close` event being emitted.
We aren't sharing streams between processes, so this edge case doesn't
apply to us. This just seemed like a more suitable event to listen to,
since we care about the process exiting not the stream ending.
See this description of the `close` event from the Node.js
documentation [1]:
>The `'close'` event is emitted when the stdio streams of a child
>process have been closed. This is distinct from the `'exit'` event,
>since multiple processes might share the same stdio streams.
And see this description of the `exit` event:
>The `'exit'` event is emitted after the child process ends.
[1]: https://nodejs.org/docs/latest-v14.x/api/child_process.html#child_process_event_exit
* build - declare background as html
* build - fill in empty file when a missing file is expected
* lint - fix
* Update development/build/manifest.js
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
* Update development/build/manifest.js
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
* Excluding sourcemaps comment in production builds
FixesMetaMask/metamask-extension#7077
* Fix source map explorer script
The source map explorer script now re-adds the source map comment to
each file to ensure the source map visualization still works. Each
module with a sourcemap is copied to a temporary directory along with
the module it corresponds to, and from there it's passed into
`source-map-explorer`. This should ensure the resulting visualization
matches what it was before.
Everything has been moved inside of functions to generally improve
readability, and to allow the use of local variables.
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
The source map explorer script will now use `yarn` instead of `npx` to
create the visualizations, to ensure that it's using the exact version
of `source-map-explorer` that we have in our dependencies.
The standard set of Bash flags have been set as well, and the standard
Bash shebang we use. This ensures the script will fail if an error is
encountered.
Build warnings related to Sass have been reduced by dynamically
importing `gulp-sass` and `sass-compiler` at the point where it's first
used. This ensures that the four Dart-related build warnings are only
emitted for the build process that is actually running Sass, rather
than by _every_ build process.
The bundle visualizations for the library bundles has been fixed.
Previously it was trying to generate a visualization for the non-
existent 'libs.js' module. Now it correctly generates a visualization
for the 'ui-libs.js` and 'bg-libs.js' modules.
The `.sh` file extension is now used for all Bash scripts. This ensures
the files are recognized as Bash scripts by the ShellCheck CI job, and
by editors/IDEs for improved syntax highlighting.
The `verify-locale-strings` script now ignores unit tests. This ensures
the use of a string literal in a unit test won't mistakenly make this
script believe that a message is used in the extension.
This came up recently in #10396, where the deletion of unit tests for
dead code triggered an unused message lint failure. This was then fixed
in #10395.
* ci - run storybook and add to build-artifacts
* ci/storybook - rename storybook build path and fix artifact upload
* ci/storybook - rename link text
* clean - remove accidently committed storybook build dir
* storybook - fix image path to relative (#10364)
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.
The environment variables `METAMETRICS_PROJECT_ID` and
`ETH_GAS_STATION_API_KEY` were still being injected into the JavaScript
build, despite being unused. The MetaMetrics project ID was made
obsolete in #9646, and the ETH Gas Station API key was made obsolete in
PR #9867
* Maintain console logging in dev mode
Co-authored-by: kumavis <aaron@kumavis.me>
Co-authored-by: Erik Marks <rekmarks@protonmail.com>
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
The Firefox e2e tests now use the `.zip` file for testing the
extension. We've found this to produce more similar results to
production, compared to the old method of loading the unzipped
directory.
Passing in a `.zip` file to the Chrome driver didn't seem to work. I
didn't investigate this further to see if it was possible, but I'm not
sure it makes a difference on Chrome anyway.
When you load an extension `.zip` file in Firefox, it fails to load
scripts with the `.cjs` file extension. However, it works if you load
the extension via the `manifest.json` file instead.
After renaming the `lockdown.cjs` file to `lockdown.js`, it works in
Firefox in all cases, regardless whether it's loaded by manifest or by
`.zip`.
* Remove use of ethgassthat; use metaswap /gasPrices api for gas price estimates
* Remove references to ethgasstation
* Pass base to BigNumber constructor in fetchExternalBasicGasEstimates
* Update ui/app/hooks/useTokenTracker.js
Co-authored-by: Erik Marks <25517051+rekmarks@users.noreply.github.com>
* Delete gas price chart
* Remove price chart css import
* Delete additional fee chart code
* Lint fix
* Delete more code no longer used after ethgasstation removal
Co-authored-by: Erik Marks <25517051+rekmarks@users.noreply.github.com>
* Freezeglobals: remove Promise freezing, add lockdown
* background & UI: temp disable sentry
* add loose-envify, dedupe symbol-observable
* use loose envify
* add symbol-observable patch
* run freezeGlobals after sentry init
* use require instead of import
* add lockdown to contentscript
* add error code in message
* try increasing node env heap size to 2048
* change back circe CI option
* make freezeGlobals an exported function
* make freezeGlobals an exported function
* use freezeIntrinsics
* pass down env to child process
* fix unknown module
* fix tests
* change back to 2048
* fix import error
* attempt to fix memory error
* fix lint
* fix lint
* fix mem gain
* use lockdown in phishing detect
* fix lint
* move sentry init into freezeIntrinsics to run lockdown before other imports
* lint fix
* custom lockdown modules per context
* lint fix
* fix global test
* remove run in child process
* remove lavamoat-core, use ses, require lockdown directly
* revert childprocess
* patch package postinstall
* revert back child process
* add postinstall to ci
* revert node max space size to 1024
* put back loose-envify
* Disable sentry to see if e2e tetss pass
* use runLockdown, add as script in manifest
* remove global and require from runlockdown
* add more memory to tests
* upgrade resource class for prep-build & prep-build-test
* fix lint
* lint fix
* upgrade remote-redux-devtools
* skillfully re-add sentry
* lintfix
* fix lint
* put back beep
* remove envify, add loose-envify and patch-package in dev deps
* Replace patch with Yarn resolution (#9923)
Instead of patching `symbol-observable`, this ensures that all
versions of `symbol-observable` are resolved to the given range, even
if it contradicts the requested range.
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
The `sentry:publish` script now exits with an exit code of `1` upon
failure, indicating that something went wrong. Previously it would exit
with a code of `0`, indicating to CI that everything worked correctly.
The script will now also exit early if the authentication check fails.
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
It was getting rather complicated to keep track of which Segment keys
were set where, and under which name.
The build script now injects a key even in test environments, but it is
unused if `IN_TEST` is truthy. This should be functionally equivalent
to the old logic. I find this simpler mainly for two reasons: there is
one less intermediate variable to keep track of now, and the `IN_TEST`
check is now directly in the module where we're constructing the
`segment` instance, rather than being referenced at a distance in a
comment.
The old setup made it difficult to turn on metrics for specific e2e
tests as well, which will be done in a subsequent PR.
