MetaMask Browser Extension

You can find the latest version of MetaMask onour official website.For help using MetaMask, visit ourUser Support Site.

Forgeneral questions,feature requests,ordeveloper questions,visit ourCommunity Forum.

MetaMask supports Firefox, Google Chrome, and Chromium-based browsers. We recommend using the latest available browser version.

For up to the minute news, follow ourTwitterorMediumpages.

To learn how to develop MetaMask-compatible applications, visit ourDeveloper Docs.

To learn how to contribute to the MetaMask codebase, visit ourContributor Docs.

To learn how to contribute to the MetaMask Extension project itself, visit ourExtension Docs.

GitHub Codespaces quickstart

As an alternative to building on your local machine, there is a new option to get a development environment up and running in less than 5 minutes by using GitHub Codespaces. Please note that there is aLimited Free Monthly Quota,and after that GitHub will start charging you.

Note: You are billed for both time spent running, and for storage used

1. Start by clicking the button above
2. A new browser tab will open with a remote version of Visual Studio Code (this will take a few minutes to load)
3. A "Simple Browser" will open inside the browser with noVNC -- click Connect
   • Optional steps:
     • Click the button at the upper-right of the Simple Browser tab to open the noVNC window in its own tab
     • Open the noVNC sidebar on the left, click the gear icon, change the Scaling Mode to Remote Resizing
4. Wait about 20 extra seconds on the first launch, for the scripts to finish
5. Right-click on the noVNC desktop to launch Chrome or Firefox with MetaMask pre-installed
6. Change some code, then runyarn startto build in dev mode
7. After a minute or two, it will finish building, and you can see your changes in the noVNC desktop

Tips to keep your Codespaces usage lower

• You are billed for both time spent running, and for storage used
• Codespaces pause after 30 minutes of inactivity, and auto-delete after 30 days of inactivity
• You can manage your Codespaces here:https://github /codespaces
  • You may want to manually pause them before the 30 minute timeout
  • If you have several idle Codespaces hanging around for several days, you can quickly run out of storage quota. You should delete the ones you do not plan to use anymore, and probably keep only 1 or 2 in the long-term. It's also possible to re-use old Codespaces and switch the branch, instead of creating new ones and deleting the old ones.

Codespaces on a fork

If you are not a MetaMask Internal Developer, or are otherwise developing on a fork, the default Infura key will be on the Free Plan and have very limited requests per second. If you want to use your own Infura key, follow the.metamaskrcandINFURA_PROJECT_IDinstructions in the sectionBuilding on your local machine.

Building on your local machine

• InstallNode.jsversion 20

  • If you are usingnvm(recommended) runningnvm usewill automatically choose the right node version for you.

• Enable Corepack by executing the commandcorepack enablewithin the metamask-extension project. Corepack is a utility included with Node.js by default. It manages Yarn on a per-project basis, using the version specified by thepackageManagerproperty in the project's package.json file. Please note that modern releases ofYarnare not intended to be installed globally or via npm.

• Duplicate.metamaskrc.distwithin the root and rename it to.metamaskrcby runningcp.metamaskrc{.dist,}.

  • Replace theINFURA_PROJECT_IDvalue with your own personalInfura API Key.
    • If you don't have an Infura account, you can create one for free on theInfura website.
  • If debugging MetaMetrics, you'll need to add a value forSEGMENT_WRITE_KEYSegment write key,seeDeveloping on MetaMask - Segment.
  • If debugging unhandled exceptions, you'll need to add a value forSENTRY_DSNSentry Dsn,seeDeveloping on MetaMask - Sentry.
  • Optionally, replace thePASSWORDvalue with your development wallet password to avoid entering it each time you open the app.

• Runyarn installto install the dependencies.

• Build the project to the./dist/folder withyarn dist(for Chromium-based browsers) oryarn dist:mv2(for Firefox)

  • Optionally, to create a development build you can instead runyarn start(for Chromium-based browsers) oryarn start:mv2(for Firefox)
  • Uncompressed builds can be found in/dist,compressed builds can be found in/buildsonce they're built.
  • See thebuild system readmefor build system usage information.

• Follow these instructions to verify that your local build runs correctly:

  • How to add custom build to Chrome
  • How to add custom build to Firefox

Git Hooks

To get quick feedback from our shared code quality fitness functions before committing the code, you can install our git hooks with Husky.

$ yarn githooks:install

You can read more about them in ourtesting documentation.

If you are using VS Code and are unable to make commits from the source control sidebar due to a "command not found" error, try these steps from theHusky docs.

Contributing

Development builds

To start a development build (e.g. with logging and file watching) runyarn start.

Development build with wallet state

You can start a development build with a preloaded wallet state, by addingTEST_SRP='<insert SRP here>'andPASSWORD='<insert wallet password here>'to the.metamaskrcfile. Then you have the following options:

1. Start the wallet with the default fixture flags, by runningyarn start:with-state.
2. Check the list of available fixture flags, by runningyarn start:with-state --help.
3. Start the wallet with custom fixture flags, by runningyarn start:with-state --FIXTURE_NAME=VALUEfor exampleyarn start:with-state --withAccounts=100.You can pass as many flags as you want. The rest of the fixtures will take the default values.

Development build with Webpack

You can also start a development build using theyarn webpackcommand, oryarn webpack --watch.This uses an alternative build system that is much faster, but not yet production ready. See theWebpack READMEfor more information.

React and Redux DevTools

To start theReact DevTools,runyarn devtools:reactwith a development build installed in a browser. This will open in a separate window; no browser extension is required.

To start theRedux DevTools Extension:

• Install the packageremotedev-serverglobally (e.g.yarn global add remotedev-server)
• Install the Redux Devtools extension.
• Open the Redux DevTools extension and check the "Use custom (local) server" checkbox in the Remote DevTools Settings, using the default server configuration (hostlocalhost,port8000,secure connection checkbox unchecked).

Then run the commandyarn devtools:reduxwith a development build installed in a browser. This will enable you to use the Redux DevTools extension to inspect MetaMask.

To create a development build and run both of these tools simultaneously, runyarn start:dev.

Test Dapp

This test sitecan be used to execute different user flows.

Running Unit Tests and Linting

Run unit tests and the linter withyarn test.To run just unit tests, runyarn test:unit.

You can run the linter by itself withyarn lint,and you can automatically fix some lint problems withyarn lint:fix.You can also run these two commands just on your local changes to save time withyarn lint:changedandyarn lint:changed:fixrespectively.

For Jest debugging guide using Node.js, seedocs/tests/jest.md.

Running E2E Tests

Our e2e test suite can be run on either Firefox or Chrome. Here's how to get started with e2e testing:

Preparing a Test Build

Before running e2e tests, ensure you've runyarn installto download dependencies. Next, you'll need a test build. You have 3 options:

1. Useyarn download-builds:testto quickly download and unzip test builds for Chrome and Firefox into the./dist/folder. This method is fast and convenient for standard testing.
2. Create a custom test build: for testing against different build types, useyarn build:test.This command allows you to generate test builds for various types, including:
   • yarn build:testfor main build
   • yarn build:test:flaskfor flask build
   • yarn build:test:mmifor mmi build
   • yarn build:test:mv2for mv2 build
3. Start a test build with live changes:yarn start:testis particularly useful for development. It starts a test build that automatically recompiles application code upon changes. This option is ideal for iterative testing and development. This command also allows you to generate test builds for various types, including:
   • yarn start:testfor main build
   • yarn start:test:flaskfor flask build
   • yarn start:test:mv2for mv2 build

Note: Theyarn start:testcommand (which initiates the testDev build type) has LavaMoat disabled for both the build system and the application, offering a streamlined testing experience during development. On the other hand,yarn build:testenables LavaMoat for enhanced security in both the build system and application, mirroring production environments more closely.

Running Tests

Once you have your test build ready, choose the browser for your e2e tests:

• For Firefox, runyarn test:e2e:firefox.
  • Note: If you are running Firefox as a snap package on Linux, ensure you enable the appropriate environment variable:FIREFOX_SNAP=true yarn test:e2e:firefox
• For Chrome, runyarn test:e2e:chrome.

These scripts support additional options for debugging. Use--helpto see all available options.

Running a single e2e test

Single e2e tests can be run withyarn test:e2e:single test/e2e/tests/TEST_NAME.spec.jsalong with the options below.

--browser Set the browser to be used; specify 'chrome', 'firefox', 'all'
or leave unset to run on 'all' by default.
[string] [default: 'all']
--debug Run tests in debug mode, logging each driver interaction
[boolean] [default: true]
--retries Set how many times the test should be retried upon failure.
[number] [default: 0]
--leave-running Leaves the browser running after a test fails, along with
anything else that the test used (ganache, the test dapp,
etc.) [boolean] [default: false]
--update-snapshot Update E2E test snapshots
[alias: -u] [boolean] [default: false]

For example, to run theaccount-detailstests using Chrome, with debug logging and with the browser set to remain open upon failure, you would use: yarn test:e2e:single test/e2e/tests/account-menu/account-details.spec.js --browser=chrome --leave-running

Running e2e tests against specific feature flag

While developing new features, we often use feature flags. As we prepare to make these features generally available (GA), we remove the feature flags. Existing feature flags are listed in the.metamaskrc.distfile. To execute e2e tests with a particular feature flag enabled, it's necessary to first generate a test build with that feature flag activated. There are two ways to achieve this:

• To enable a feature flag in your local configuration, you should first ensure you have a.metamaskrcfile copied from.metamaskrc.dist.Then, within your local.metamaskrcfile, you can set the desired feature flag to true. Following this, a test build with the feature flag enabled can be created by executingyarn build:test.

• Alternatively, for enabling a feature flag directly during the test build creation, you can pass the parameter as true via the command line. For instance, activating the MULTICHAIN feature flag can be done by runningMULTICHAIN=1 yarn build:testorMULTICHAIN=1 yarn start:test.This method allows for quick adjustments to feature flags without altering the.metamaskrcfile.

Once you've created a test build with the desired feature flag enabled, proceed to run your tests as usual. Your tests will now run against the version of the extension with the specific feature flag activated. For example: yarn test:e2e:single test/e2e/tests/account-menu/account-details.spec.js --browser=chrome

This approach ensures that your e2e tests accurately reflect the user experience for the upcoming GA features.

Running specific builds types e2e test

Different build types have different e2e tests sets. In order to run them look in thepackage.jsonfile. You will find:

"test:e2e:chrome:mmi": "SELENIUM_BROWSER=chrome node test/e2e/run-all.js --mmi",
"test:e2e:chrome:snaps": "SELENIUM_BROWSER=chrome node test/e2e/run-all.js --snaps",
"test:e2e:firefox": "ENABLE_MV3=false SELENIUM_BROWSER=firefox node test/e2e/run-all.js",

Note: Running MMI e2e tests

When running e2e on an MMI build you need to know that there are 2 separated set of tests:

• MMI runs a subset of MetaMask's e2e tests. To facilitate this, we have appended the@no-mmitags to the names of those tests that are not applicable to this build type.
• MMI runs another specific set of e2e legacy tests which are better documentedhere

Changing dependencies

Whenever you change dependencies (adding, removing, or updating, either inpackage.jsonoryarn.lock), there are various files that must be kept up-to-date.

• yarn.lock:
  • Runyarnagain after your changes to ensureyarn.lockhas been properly updated.
  • Runyarn lint:lockfile:dedupe:fixto remove duplicate dependencies from the lockfile.
• Theallow-scriptsconfiguration inpackage.json
  • Runyarn allow-scripts autoto update theallow-scriptsconfiguration 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 autowill behave inconsistently on different platforms. macOS and Windows users may see extraneous changes relating to optional dependencies.
• The LavaMoat policy files
  • If you are a MetaMask team member and your PR is on a repository branch, you can use the bot command@metamaskbot update-policiesto ask the MetaMask bot to automatically update the policies for you.
  • If your PR is from a fork, you can ask a MetaMask team member to help with updating the policy files.
  • Manual update instructions: Thetl;dris to runyarn lavamoat:autoto update these files, but there can be devils in the details:
    • There are two sets of LavaMoat policy files:
      • The production LavaMoat policy files (lavamoat/browserify/*/policy.json), which are re-generated usingyarn lavamoat:webapp:auto.Add--helpfor usage.
        • These should be regenerated whenever the production dependencies for the webapp change.
      • The build system LavaMoat policy file (lavamoat/build-system/policy.json), which is re-generated usingyarn lavamoat:build:auto.
        • This should be regenerated whenever the dependencies used by the build system itself change.
    • Whenever you regenerate a policy file, review the changes to determine whether the access granted to each package seems appropriate.
    • Unfortunately,yarn lavamoat:autowill behave inconsistently on different platforms. macOS and Windows users may see extraneous changes relating to optional dependencies.
    • If you keep getting policy failures even after regenerating the policy files, try regenerating the policies after a clean install by doing:
      • rm -rf node_modules/ && yarn && yarn lavamoat:auto
    • Keep in mind that any kind of dynamic import or dynamic use of globals may elude LavaMoat's static analysis. Refer to the LavaMoat documentation or ask for help if you run into any issues.
• The Attributions file
  • If you are a MetaMask team member and your PR is on a repository branch, you can use the bot command@metamaskbot update-attributionsto ask the MetaMask bot to automatically update the attributions file for you.
  • Manual update: runyarn attributions:generate.

Architecture

• Visual of the controller hierarchy and dependencies as of summer 2022.
• Visual of the entire codebase.

Other Docs

• How to add a new translation to MetaMask
• Publishing Guide
• How to use the TREZOR emulator
• Developing on MetaMask
• How to generate a visualization of this repository's development
• How to add new confirmations
• Browser support guidelines

Dapp Developer Resources

• Extend MetaMask's features w/ MetaMask Snaps.
• Prompt your users to add and switch to a new network.
• Change the logo that appears when your dapp connects to MetaMask.