Our JSDoc documentation has not been updated in a very long time, and
we don't use JSDoc in enough places for the docs to have been
especially useful. The tools and scripts used to generate and publish
these docs have been removed.
References to this documentation have also been removed from the
README.
Hopefully once the TypeScript migration has made substantial progress,
we can generate more useful documentation using something like TypeDoc.
The Storybook deploy step is currently broken because it's using the
wrong source branch (`master` instead of `develop`), and because the
key that CircleCI is setup with doesn't have write access to the repo.
While I expect we'll get these two problems fixed soon, this ensures
that we at least have passing builds on `develop` in the meantime.
* Minimum changes to get storybook working
Undo path changes
* Add build:storybook scripts to package.json
* Add storybook deployer
* Add storybook:deploy to package.json
* Update circle ci config
* Update yarn.lock
* Remove addon-info
* Update yarn.lock file to reflect removing of addon-info
Co-authored-by: Dan J Miller <danjm.com@gmail.com>
* Add benchmark to CI
The page load benchmark for Chrome is now run during CI, and the
results are collected and summarized in the `metamaskbot` comment.
Closes#6881
* Double default number of samples
The number of default samples was changed from 10 to 20. The results
from 10 samples would show statistically significant changes in page
load times between builds, so weren't a sufficiently useful metric.
This reverts commit 4b4c00e94f. The
original change was a possible optimization of CI, though it ended up
not having a huge impact. It was thought that it may have broken source
maps, because the test build overwrote the `dist` directory that the
source maps were written to. However this turned out not to be the
case, as the changes to `dist` are never persisted to the workspace.
This is being re-introduced because the test build is needed for an
additional job (the page load benchmark), and sharing the same build
for all three jobs would surely be faster than building it separately
three times.
* Add shellcheck lint script
* Add to build
* Add shellcheck lint to main lint task
* Put shellcheck in the right place, hopefully?
* Fix declared multiple executor types
* Add sudo
* Address shellcheck warnings
* Add test-lint-shellcheck
* Add test-lint-shellcheck to workflow
* Use correct lint task
* output version which could be helpful for debugging
* Address PR feedback
* consistency++
* Cleanup beforeunload handler after transaction is resolved
The notification window was updated to reject transactions upon close
in #6340. A handler that rejects the transaction was added to
`window.onbeforeunload`, and it was cleared in `actions.js` if it was
confirmed or rejected.
However, the `onbeforeunload` handler remained uncleared if the
transaction was resolved in another window. This results in the
transaction being rejected when the notification window closes, even
long after the transaction is submitted and confirmed. This has been
the cause of many problems with the Firefox e2e tests.
Instead the `onbeforeunload` handler is cleared in the
`componentWillUnmount` lifecycle function, alongside where it's set in
the first place. This ensures that it's correctly unset regardless
of how the transaction was resolved, and it better matches user
expectations.
* Fix indentation and remove redundant export
The `run-all.sh` Bash script now uses consistent indentation, and is
consistent about only re-exporting the Ganache arguments when they
change.
* Ensure transactions are completed before checking balance
Various intermittent e2e test failures appear to be caused by React
re-rendering the transaction list during the test, as the transaction
goes from pending to confirmed. To avoid this race condition, the
transaction is now explicitly looked for in the confirmed transaction
list in each of the tests using this pattern.
* Enable all e2e tests on Firefox
The remaining tests that were disabled on Firefox now work correctly.
Only a few timing adjustments were needed.
* Update Firefox used in CI
Firefox v70 is now used on CI instead of v68. This necessitated
rewriting the function where the extension ID was obtained because the
Firefox extensions page was redesigned.
* ci - install deps - limit install scripts to those needed for build
* Update .circleci/scripts/deps-install.sh
Co-Authored-By: Mark Stacey <markjstacey@gmail.com>
* ci - install deps - expand install scripts needed for tests
* ci - install deps - expand install scripts needed for integration tests
* ci - install deps - fix node-sass script ref
* github - set codeowners for scripts/deps-install
* development - add utility to show deps with install scripts
* lint fix
* deps - move read-installed to devDeps
* Use common test build during CI
Previously both e2e test jobs were running `test:build`. Now there is a
separate job that runs `test:build` that runs before each e2e test job,
so that `test:build` is only run once instead of twice.
* Move test builds to separate directory
This prevents the test build from conflicting with the production build
in later jobs.
* Add '--quiet' flag to verify locales script
The `--quiet` flag reduces the console output to just the essential
information for running in a CI environment. For each locale, it will
print the number of unused messages (if any).
* Add `verify-locales` script to lint CI job
The locales are now verified as part of the lint CI job. Any unused
messages detected will result in the job failing.
* ci - install deps with "--har" flag to capture network activity
* ci - add yarn install HAR logs to build-artifacts
* ci - yarn har - fix typo
* Update .circleci/scripts/collect-har-artifact.sh
Co-Authored-By: Mark Stacey <markjstacey@gmail.com>
* ci - create source-map-explorer build-artifacts
* ci - add source-map-explorer builds to metamaskbot comment
* lint fix
* ci - source-map-explorer - include all bundles
* Publish GitHub release from master branch
This ensures that changes made on `develop` since branching for the
release are not included. It also ensures that the final release
sourcemaps line-up correctly (they were always build on master)`.
* Consolidate publish jobs
The jobs `job-publish-release` and `create_github_release` both handle
different parts of publishing a release. They have been consolidated
into a single `job-publish-release` job.
* Update release script to expect a merge commit
The release script was originally written to be run on `develop`, so it
expected the current commit to be a result of `Squash & Merge`. Now
that it's run on `master`, it will generally be run against a merge
commit.
The version is now extracted from the commit message using a regular
expression that should work on all version of Bash v3+, and should be
tolerant of both merge commits and `Squash & Merge` commits.
* Target `master` with release PR
`master` is now targeted by the release PR instead of `develop`, as
the release has to be created from the master branch.
The update to `develop` is handled after the release by a PR from
`master` to `develop`, which is created automatically after the
release.
* Publish GitHub release from master branch
This ensures that changes made on `develop` since branching for the
release are not included. It also ensures that the final release
sourcemaps line-up correctly (they were always build on master)`.
* Consolidate publish jobs
The jobs `job-publish-release` and `create_github_release` both handle
different parts of publishing a release. They have been consolidated
into a single `job-publish-release` job.
* Update release script to expect a merge commit
The release script was originally written to be run on `develop`, so it
expected the current commit to be a result of `Squash & Merge`. Now
that it's run on `master`, it will generally be run against a merge
commit.
The version is now extracted from the commit message using a regular
expression that should work on all version of Bash v3+, and should be
tolerant of both merge commits and `Squash & Merge` commits.
* Target `master` with release PR
`master` is now targeted by the release PR instead of `develop`, as
the release has to be created from the master branch.
The update to `develop` is handled after the release by a PR from
`master` to `develop`, which is created automatically after the
release.
As a solution to the constant lockfile churn issues we've had with
`npm`, the project now uses `yarn` to manage dependencies.
The `package-lock.json` file has been replaced with `yarn.lock`, which
was created using `yarn import`. It should approximate the contents of
`package-lock.json` fairly well, though there may be some changes due to
deduplication. The codeowners file has been updated to reference this
new lockfile.
All documentation and npm scripts have been updated to reference `yarn`
rather than `npm`. Note that running scripts using `npm run` still works
fine, but it seemed better to switch those to `yarn` as well to avoid
confusion.
The `npm-audit` Bash script has been replaced with `yarn-audit`. The
output of `yarn audit` is a bit different than `npm audit` in that it
returns a bitmask to describe which severity issues were found. This
made it simpler to check the results directly from the Bash script, so
the associated `npm-audit-check.js` script was no longer required. The
output should be exactly the same, and the information is still sourced
from the same place (the npm registry).
The new `yarn-audit` script does have an external dependency: `jq`.
However, `jq` is already assumed to be present by another CI script, and
is present on all CI images we use. `jq` was not added to `package.json`
as a dependency because there is no official package on the npm
registry, just wrapper scripts. We don't need it anywhere exept on CI
anyway.
The section in `CONTRIBUTING` about how to develop inside the
`node_modules` folder was removed, as the advice was a bit dated, and
wasn't specific to this project anyway.
The npm audit script was auditing all dependencies, then filtering the
results to just the advisories concerning production dependencies. This
was done by checking the boolean `dev` and `optional` properties of each
`findings` entry in each advisory.
The `dev` and `optional` properties are now missing, which is resulting
in dev advisories being mistakenly identified as affecting production.
This check has been removed, and instead the `--production` flag is used
when calling `npm audit`. This accomplishes the same goal without
relying as much upon the audit output format.
The `--production` flag was added in `npm` `v6.10.0`, so `npm` has been
updated to the current latest stable (`v6.10.2`) for the `test-deps`
job. It was also updated on the `prep-deps-npm` job to ensure
consistency in behaviour. The other jobs only use `npm run` which hasn't
changed substantially in some time, so compatibility isn't really a
concern for those.
`audit.json` has also been added to `.gitignore`. It was accidentally
checked in once while working on this branch.
* ci: Rename full_test to test_and_release
* ci: Add scripts to automate GH releases
* Add .bak files to .gitignore
* ci: Add reviewer to the auto version PR
The Drizzle tests have not been used for some time. They were used to
ensure compatibility with newer versions of `web3` v1. If we want to
re-add tests to ensure compatibility with newer `web3` versions, we
should find some way of doing that more reliably than was done here -
these tests were somewhat flaky and unreliable.
`addons-linter` will occasionally run out of heap space. This provides 3
GB of heap for that script rather than the default ~1.5 GB. The CircleCI
containers have 4GB of memory, so this should leave plenty of extra
space for non-heap memory.
The MetaMask bot is currently failing to publish docs updates, and it is
[blocking our ability to release new
versions](https://github.com/MetaMask/metamask-extension/pull/6765).
While we should pursue a proper fix, I think it's worth disabling in the
meanwhile so this glitch doesn't interfere with our regular release
cadence further.
Auditing packages when installing here doesn't help anyone as the summary
isn't visible and vulnerabilities don't produce a non-zero exit code. We
will have `npm audit` as an extra CI job.
Mark Stacey
ricky
Whymarrh Whitby
Erik Marks
kumavis
Dan Finlay
Thomas Huang