This PR adds build-time code exclusion by means of code fencing. For details, please see the README in `./development/build/transforms`. Note that linting of transformed files as a form of validation is added in a follow-up, #12075.
Hopefully exhaustive tests are added to ensure that the transform works according to its specification. Since these tests are Node-only, they required their own Jest config. The recommended way to work with multiple Jest configs is using the `projects` field in the Jest config, however [that feature breaks coverage collection](https://github.com/facebook/jest/issues/9628). That being the case, I had to set up two separate Jest configs. In order to get both test suites to run in parallel, Jest is now invoked via a script, `./test/run-jest.sh`.
By way of example, this build system feature allows us to add fences like this:
```javascript
this.store.updateStructure({
...,
GasFeeController: this.gasFeeController,
TokenListController: this.tokenListController,
///: BEGIN:ONLY_INCLUDE_IN(beta)
PluginController: this.pluginController,
///: END:ONLY_INCLUDE_IN
});
```
Which at build time are transformed to the following if the build type is not `beta`:
```javascript
this.store.updateStructure({
...,
GasFeeController: this.gasFeeController,
TokenListController: this.tokenListController,
});
```
Co-authored-by: Mark Stacey <markjstacey@gmail.com>
This rationalizes how arguments are passed to and parsed by the build system. To accomplish this, everything that isn't an environment variable from `.metamaskrc` or our CI environment is now passed as an argument on the command line.
Of such arguments, the `entryTask` is still expected as a positional argument in the first position (i.e. `process.argv[2]`), but everything else must be passed as a named argument. We use `minimist` to parse the arguments, and set defaults to preserve existing behavior.
Arguments are parsed in a new function, `parseArgv`, in `development/build/index.js`. They are assigned to environment variables where convenient, and otherwise returned from `parseArgv` to be passed to other functions invoked in the same file.
This change is motivated by our previous inconsistent handling of arguments to the build system, which will grow increasingly problematic as the build system grows in complexity. (Which it will very shortly, as we introduce Flask builds.)
Miscellaneous changes:
- Adds a build system readme at `development/build/README.md`
- Removes the `beta` package script. Now, we can instead call: `yarn dist --build-type beta`
- Fixes the casing of some log messages and reorders some parameters in the build system
There are a few issues encountered when running `yarn setup` on new
Apple Silicon (aka M1, aka arm64) Macs:
* The script halts when attempting to run the install step for
the `chromedriver` package with the message "Only Mac 64 bits
supported". This is somewhat misleading as it seems to indicate that
chromedriver can only be installed on a 64-bit Mac. However, what I
think is happening is that the installation script for `chromedriver`
is not able to detect that an arm64 CPU *is* a 64-bit CPU. After
looking through the `chromedriver` repo, it appears that 87.0.1 is the
first version that adds a proper check ([1]).
Note that upgrading chromedriver caused the Chrome-specific tests to
fail intermittently on CI. I was not able to 100% work out the reason
for this, but ensuring that X (which provides a way for Chrome to run
in a GUI setting from the command line) is available seems to fix
these issues.
* The script also halts when attempting to run the install step for
the `electron` package. This happens because for the version of
`electron` we are using (9.4.2), there is no available binary for
arm64. It appears that Electron 11.x was the first version to support
arm64 Macs ([2]). This is a bit trickier to resolve because we don't
explicitly rely on `electron` — that's brought in by `react-devtools`.
The first version of `react-devtools` that relies on `electron` 11.x
is 4.11.0 ([3]).
[1]: 469dd0a6ee
[2]: https://www.electronjs.org/blog/apple-silicon
[3]: https://github.com/facebook/react/blob/main/packages/react-devtools/CHANGELOG.md#4110-april-9-2021
This adds an `--omit-lockdown` flag to our build script, which will cause SES `lockdown` to be omitted from the resulting bundle. Useful for development when we don't want the environment to be locked down.
Thanks to @kumavis for the suggestion.
This PR makes ~all named intrinsics in all of our JavaScript processes non-modifiable. A named intrinsic is any property specified by the ECMAScript specification that exists on `globalThis` when the JavaScript process starts. We say that a property is non-modifiable if it is non-configurable and non-writable. We make exceptions for properties that meet any of the following criteria:
1. Properties that are non-configurable by the time `lockdown-run.js` is executed are not modified, because they can't be.
2. Properties that have accessor properties (`get` or `set`) are made non-configurable, but their writability cannot be modified, and is therefore left unchanged. It's unclear how many of the named intrinsics this applies to, if any, but it's good defensive programming, regardless.
The Sentry `release` was not being configured correctly. It was being
left blank. This is because the location of the extension version was
moved in #11029. The build script was correctly updated in that PR, but
that work was accidentally undone in a merge error that was included
in #11080.
Fixing up tests and add back old custom gas modal for non-eip1559 compliant networks
Remove unnecessary props from send-gas-row.component
fix breaking test
Fix primary and secondary title overrides
fix rebase issue
Fix rebase conflict
Co-authored-by: David Walsh <davidwalsh83@gmail.com>
The benchmark script can now be set to retry upon failure, like the E2E
tests do. The default is zero, just as with the E2E tests. A retry of 2
has been set in CI to match the E2E tests as well.
The `retry` module had to be adjusted to throw an error in the case of
failure. Previously it just set the exit code, but that only worked
because it was the last thing called before the process ended. That is
no longer the case.
This script makes it easier to run an individual E2E test. In the past
I've run individual scripts by editing `run-all.sh` manually, but now
that can be done more easily with this script. It also allows setting
the number of retries to use and the browser to use from the CLI.
This script has been added as an npm script as well, called
'test:e2e:single'.
The `run-all.sh` script was rewritten in JavaScript to make it easier
to pass through a `--retries` argument.
The default number of retries has been set to zero to make local
testing easier. It has been set to 2 on CI.
This was mainly done to consolidate the code used to run an E2E test in
one place, to make later improvements easier.
The function we were using to run shell commands during the
`sentry:publish` script were swallowing the CLI output. We also weren't
correctly detecting the process exit in some cases.
The `run-command` module originally written for `auto-changelog`
(introduced in #10782 and replaced in #10993) has been resurrected for
running commands where we don't care about the output, or where we want
to use the output for something. A second function (`runInShell`) has
been added for running commands with the same STDOUT and STDERR
streams, so that the output is sent directly to the CLI. This ensures
that the console output from the shell script we run gets correctly
output to the CLI.
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
The method used for uploading release artifacts to Sentry has been
updated to allow `sentry-cli` to associate our minified bundles with
the corresponding source map file. This should help Sentry display rich
stack traces.
Previously Sentry had used the `sourceMappingURL` to associate source
maps with bundles, but we recently removed this in #10695. The hope is
that this change to the upload process will ensure the mapping works
correctly without the `sourceMappingURL` comment.
The `upload_bundles` function was removed because the later
`upload_sourcemaps` function actually uploaded both the bundles and
source maps.
The `--rewrite` flag was added to enable a newer "rewrite" feature of
the Sentry CLI that they recommend using [1]. This rewrite is where
they associate source maps with bundles.
The `url-prefix` has been updated to be `metamask` rather than
`sourcemaps`. I don't think `sourcemaps` was ever the correct prefix.
We normalize our errors to have the path `metamask/` before sending any
reports to Sentry.
[1]: https://docs.sentry.io/product/cli/releases/#sentry-cli-sourcemaps
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 `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 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>
