# MetaMask Browser Extension
Hey! We are hiring JavaScript Engineers! [Apply here ](https://boards.greenhouse.io/consensys/jobs/2572388 )!
---
You can find the latest version of MetaMask on [our official website ](https://metamask.io/ ). For help using MetaMask, visit our [User Support Site ](https://metamask.zendesk.com/hc/en-us ).
For [general questions ](https://community.metamask.io/c/learn/26 ), [feature requests ](https://community.metamask.io/c/feature-requests-ideas/13 ), or [developer questions ](https://community.metamask.io/c/developer-questions/11 ), visit our [Community Forum ](https://community.metamask.io/ ).
MetaMask supports Firefox, Google Chrome, and Chromium-based browsers. We recommend using the latest available browser version.
For up to the minute news, follow our [Twitter ](https://twitter.com/metamask ) or [Medium ](https://medium.com/metamask ) pages.
To learn how to develop MetaMask-compatible applications, visit our [Developer Docs ](https://metamask.github.io/metamask-docs/ ).
To learn how to contribute to the MetaMask project itself, visit our [Internal Docs ](https://github.com/MetaMask/metamask-extension/tree/develop/docs ).
## Building locally
- Install [Node.js ](https://nodejs.org ) version 14
- If you are using [nvm ](https://github.com/creationix/nvm#installation ) (recommended) running `nvm use` will automatically choose the right node version for you.
Switch from `npm` to `yarn` (#6843)
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.
5 years ago
- Install [Yarn ](https://yarnpkg.com/en/docs/install )
- Install dependencies: `yarn setup` (not the usual install command)
- Copy the `.metamaskrc.dist` file to `.metamaskrc`
- Replace the `INFURA_PROJECT_ID` value with your own personal [Infura Project ID ](https://infura.io/docs ).
- If debugging MetaMetrics, you'll need to add a value for `SEGMENT_WRITE_KEY` [Segment write key ](https://segment.com/docs/connections/find-writekey/ ).
Switch from `npm` to `yarn` (#6843)
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.
5 years ago
- Build the project to the `./dist/` folder with `yarn dist` .
Uncompressed builds can be found in `/dist` , compressed builds can be found in `/builds` once they're built.
Rationalize build system arguments (#12047)
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
3 years ago
See the [build system readme ](./development/build/README.md ) for build system usage information.
## Contributing
### Development builds
To start a development build (e.g. with logging and file watching) run `yarn start` .
To start the [React DevTools ](https://github.com/facebook/react-devtools ) and [Redux DevTools Extension ](https://github.com/reduxjs/redux-devtools/tree/main/extension )
alongside the app, use `yarn start:dev` .
- React DevTools will open in a separate window; no browser extension is required
- Redux DevTools will need to be installed as a browser extension. Open the Redux Remote Devtools to access Redux state logs. This can be done by either right clicking within the web browser to bring up the context menu, expanding the Redux DevTools panel and clicking Open Remote DevTools OR clicking the Redux DevTools extension icon and clicking Open Remote DevTools.
- You will also need to check the "Use custom (local) server" checkbox in the Remote DevTools Settings, using the default server configuration (host `localhost` , port `8000` , secure connection checkbox unchecked)
[Test site ](https://metamask.github.io/test-dapp/ ) can be used to execute different user flows.
### Running Unit Tests and Linting
Run unit tests and the linter with `yarn test` . To run just unit tests, run `yarn test:unit` .
You can run the linter by itself with `yarn lint` , and you can automatically fix some lint problems with `yarn lint:fix` . You can also run these two commands just on your local changes to save time with `yarn lint:changed` and `yarn lint:changed:fix` respectively.
### Running E2E Tests
Our e2e test suite can be run on either Firefox or Chrome. In either case, start by creating a test build by running `yarn build:test` .
Firefox e2e tests can be run with `yarn test:e2e:firefox` .
Chrome e2e tests can be run with `yarn test:e2e:chrome` , but they will only work if you have Chrome v79 installed. Update the `chromedriver` package to a version matching your local Chrome installation to run e2e tests on newer Chrome versions.
### Changing dependencies
Whenever you change dependencies (adding, removing, or updating, either in `package.json` or `yarn.lock` ), there are various files that must be kept up-to-date.
* `yarn.lock` :
* Run `yarn setup` again after your changes to ensure `yarn.lock` has been properly updated.
* The `allow-scripts` configuration in `package.json`
* Run `yarn allow-scripts auto` to update the `allow-scripts` configuration automatically. This config determines whether the package's install/postinstall scripts are allowed to run. Review each new package to determine whether the install script needs to run or not, testing if necessary.
* Unfortunately, `yarn allow-scripts auto` will behave inconsistently on different platforms. macOS and Windows users may see extraneous changes relating to optional dependencies.
* The LavaMoat auto-generated policy in `lavamoat/node/policy.json`
* Run `yarn lavamoat:auto` to re-generate this policy file. Review the changes to determine whether the access granted to each package seems appropriate.
* Unfortunately, `yarn lavamoat:auto` will behave inconsistently on different platforms. macOS and Windows users may see extraneous changes relating to optional dependencies.
## Architecture
[][1]
## Development
```bash
Switch from `npm` to `yarn` (#6843)
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.
5 years ago
yarn
yarn start
```
## Build for Publishing
```bash
Switch from `npm` to `yarn` (#6843)
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.
5 years ago
yarn dist
```
## Other Docs
- [How to add custom build to Chrome ](./docs/add-to-chrome.md )
- [How to add custom build to Firefox ](./docs/add-to-firefox.md )
- [How to add a new translation to MetaMask ](./docs/translating-guide.md )
- [Publishing Guide ](./docs/publishing.md )
- [How to use the TREZOR emulator ](./docs/trezor-emulator.md )
- [How to generate a visualization of this repository's development ](./development/gource-viz.sh )
[1]: http://www.nomnoml.com/#view/%5B%3Cactor%3Euser%5D%0A%0A%5Bmetamask-ui%7C%0A%20%20%20%5Btools%7C%0A%20%20%20%20%20react%0A%20%20%20%20%20redux%0A%20%20%20%20%20thunk%0A%20%20%20%20%20ethUtils%0A%20%20%20%20%20jazzicon%0A%20%20%20%5D%0A%20%20%20%5Bcomponents%7C%0A%20%20%20%20%20app%0A%20%20%20%20%20account-detail%0A%20%20%20%20%20accounts%0A%20%20%20%20%20locked-screen%0A%20%20%20%20%20restore-vault%0A%20%20%20%20%20identicon%0A%20%20%20%20%20config%0A%20%20%20%20%20info%0A%20%20%20%5D%0A%20%20%20%5Breducers%7C%0A%20%20%20%20%20app%0A%20%20%20%20%20metamask%0A%20%20%20%20%20identities%0A%20%20%20%5D%0A%20%20%20%5Bactions%7C%0A%20%20%20%20%20%5BbackgroundConnection%5D%0A%20%20%20%5D%0A%20%20%20%5Bcomponents%5D%3A-%3E%5Bactions%5D%0A%20%20%20%5Bactions%5D%3A-%3E%5Breducers%5D%0A%20%20%20%5Breducers%5D%3A-%3E%5Bcomponents%5D%0A%5D%0A%0A%5Bweb%20dapp%7C%0A%20%20%5Bui%20code%5D%0A%20%20%5Bweb3%5D%0A%20%20%5Bmetamask-inpage%5D%0A%20%20%0A%20%20%5B%3Cactor%3Eui%20developer%5D%0A%20%20%5Bui%20developer%5D-%3E%5Bui%20code%5D%0A%20%20%5Bui%20code%5D%3C-%3E%5Bweb3%5D%0A%20%20%5Bweb3%5D%3C-%3E%5Bmetamask-inpage%5D%0A%5D%0A%0A%5Bmetamask-background%7C%0A%20%20%5Bprovider-engine%5D%0A%20%20%5Bhooked%20wallet%20subprovider%5D%0A%20%20%5Bid%20store%5D%0A%20%20%0A%20%20%5Bprovider-engine%5D%3C-%3E%5Bhooked%20wallet%20subprovider%5D%0A%20%20%5Bhooked%20wallet%20subprovider%5D%3C-%3E%5Bid%20store%5D%0A%20%20%5Bconfig%20manager%7C%0A%20%20%20%20%5Brpc%20configuration%5D%0A%20%20%20%20%5Bencrypted%20keys%5D%0A%20%20%20%20%5Bwallet%20nicknames%5D%0A%20%20%5D%0A%20%20%0A%20%20%5Bprovider-engine%5D%3C-%5Bconfig%20manager%5D%0A%20%20%5Bid%20store%5D%3C-%3E%5Bconfig%20manager%5D%0A%5D%0A%0A%5Buser%5D%3C-%3E%5Bmetamask-ui%5D%0A%0A%5Buser%5D%3C%3A--%3A%3E%5Bweb%20dapp%5D%0A%0A%5Bmetamask-contentscript%7C%0A%20%20%5Bplugin%20restart%20detector%5D%0A%20%20%5Brpc%20passthrough%5D%0A%5D%0A%0A%5Brpc%20%7C%0A%20%20%5Bethereum%20blockchain%20%7C%0A%20%20%20%20%5Bcontracts%5D%0A%20%20%20%20%5Baccounts%5D%0A%20%20%5D%0A%5D%0A%0A%5Bweb%20dapp%5D%3C%3A--%3A%3E%5Bmetamask-contentscript%5D%0A%5Bmetamask-contentscript%5D%3C-%3E%5Bmetamask-background%5D%0A%5Bmetamask-background%5D%3C-%3E%5Bmetamask-ui%5D%0A%5Bmetamask-background%5D%3C-%3E%5Brpc%5D%0A
