Merge branch 'main' into add-more-testing-guidelines

.gitattributes

@@ -0,0 +1,8 @@
+* text=auto
+
+yarn.lock linguist-generated=false
+
+# yarn v3
+# See: https://yarnpkg.com/getting-started/qa#which-files-should-be-gitignored
+/.yarn/releases/** binary
+/.yarn/plugins/** binary

.github/CODEOWNERS

@@ -0,0 +1,4 @@
+# Lines starting with '#' are comments.
+# Each line is a file pattern followed by one or more owners.
+
+*                                    @MetaMask/engineering

.github/dependabot.yml

@@ -0,0 +1,15 @@
+# Please see the documentation for all configuration options:
+# https://docs.github.com/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file
+
+version: 2
+updates:
+  - package-ecosystem: 'npm'
+    directory: '/'
+    schedule:
+      interval: 'daily'
+      time: '06:00'
+    allow:
+      - dependency-name: '@metamask/*'
+    target-branch: 'main'
+    versioning-strategy: 'increase-if-necessary'
+    open-pull-requests-limit: 10

.github/workflows/main.yml

@@ -0,0 +1,41 @@
+name: Main
+
+on:
+  push:
+    branches: [main]
+  pull_request:
+
+jobs:
+  check-workflows:
+    name: Check workflows
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v3
+      - name: Download actionlint
+        id: download-actionlint
+        run: bash <(curl https://raw.githubusercontent.com/rhysd/actionlint/7fdc9630cc360ea1a469eed64ac6d78caeda1234/scripts/download-actionlint.bash) 1.6.23
+        shell: bash
+      - name: Check workflow files
+        run: ${{ steps.download-actionlint.outputs.executable }} -color
+        shell: bash
+
+  lint:
+    name: Lint
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v3
+      - name: Use Node.js
+        uses: actions/setup-node@v3
+        with:
+          node-version-file: '.nvmrc'
+          cache: 'yarn'
+      - name: Install Yarn dependencies
+        run: yarn --immutable
+      - run: yarn lint
+      - name: Require clean working directory
+        shell: bash
+        run: |
+          if ! git diff --exit-code; then
+            echo "Working tree dirty at end of job"
+            exit 1
+          fi

.gitignore

@@ -0,0 +1,78 @@
+.DS_Store
+dist/
+coverage/
+docs/
+
+# Logs
+logs
+*.log
+npm-debug.log*
+yarn-debug.log*
+yarn-error.log*
+lerna-debug.log*
+
+# Diagnostic reports (https://nodejs.org/api/report.html)
+report.[0-9]*.[0-9]*.[0-9]*.[0-9]*.json
+
+# Runtime data
+pids
+*.pid
+*.seed
+*.pid.lock
+
+# Coverage directory used by tools like istanbul
+coverage
+*.lcov
+
+# nyc test coverage
+.nyc_output
+
+# node-waf configuration
+.lock-wscript
+
+# Compiled binary addons (https://nodejs.org/api/addons.html)
+build/Release
+
+# Dependency directories
+node_modules/
+
+# TypeScript cache
+*.tsbuildinfo
+
+# Optional npm cache directory
+.npm
+
+# Optional eslint cache
+.eslintcache
+
+# Microbundle cache
+.rpt2_cache/
+.rts2_cache_cjs/
+.rts2_cache_es/
+.rts2_cache_umd/
+
+# Optional REPL history
+.node_repl_history
+
+# Output of 'npm pack'
+*.tgz
+
+# Yarn Integrity file
+.yarn-integrity
+
+# dotenv environment variables file
+.env
+.env.test
+
+# Stores VSCode versions used for testing VSCode extensions
+.vscode-test
+
+# yarn v3 (w/o zero-install)
+# See: https://yarnpkg.com/getting-started/qa#which-files-should-be-gitignored
+.pnp.*
+.yarn/*
+!.yarn/patches
+!.yarn/plugins
+!.yarn/releases
+!.yarn/sdks
+!.yarn/versions

.nvmrc

@@ -0,0 +1 @@
+v16

.prettierrc.js

@@ -0,0 +1,8 @@
+// All of these are defaults except singleQuote, but we specify them
+// for explicitness
+module.exports = {
+  quoteProps: 'as-needed',
+  singleQuote: true,
+  tabWidth: 2,
+  trailingComma: 'all',
+};

.yarn/plugins/@yarnpkg/plugin-allow-scripts.cjs

@@ -0,0 +1,9 @@
+/* eslint-disable */
+//prettier-ignore
+module.exports = {
+name: "@yarnpkg/plugin-allow-scripts",
+factory: function (require) {
+var plugin=(()=>{var a=Object.create,l=Object.defineProperty;var i=Object.getOwnPropertyDescriptor;var s=Object.getOwnPropertyNames;var p=Object.getPrototypeOf,c=Object.prototype.hasOwnProperty;var u=e=>l(e,"__esModule",{value:!0});var f=e=>{if(typeof require!="undefined")return require(e);throw new Error('Dynamic require of "'+e+'" is not supported')};var g=(e,o)=>{for(var r in o)l(e,r,{get:o[r],enumerable:!0})},m=(e,o,r)=>{if(o&&typeof o=="object"||typeof o=="function")for(let t of s(o))!c.call(e,t)&&t!=="default"&&l(e,t,{get:()=>o[t],enumerable:!(r=i(o,t))||r.enumerable});return e},x=e=>m(u(l(e!=null?a(p(e)):{},"default",e&&e.__esModule&&"default"in e?{get:()=>e.default,enumerable:!0}:{value:e,enumerable:!0})),e);var k={};g(k,{default:()=>d});var n=x(f("@yarnpkg/shell")),y={hooks:{afterAllInstalled:async()=>{let e=await(0,n.execute)("yarn run allow-scripts");e!==0&&process.exit(e)}}},d=y;return k;})();
+return plugin;
+}
+};

.yarnrc.yml

@@ -0,0 +1,17 @@
+enableScripts: false
+
+enableTelemetry: 0
+
+logFilters:
+  - code: YN0004
+    level: discard
+
+nodeLinker: node-modules
+
+plugins:
+  - path: .yarn/plugins/@yarnpkg/plugin-allow-scripts.cjs
+    spec: "https://raw.githubusercontent.com/LavaMoat/LavaMoat/main/packages/yarn-plugin-allow-scripts/bundles/@yarnpkg/plugin-allow-scripts.js"
+  - path: .yarn/plugins/@yarnpkg/plugin-constraints.cjs
+    spec: "@yarnpkg/plugin-constraints"
+
+yarnPath: .yarn/releases/yarn-3.2.1.cjs

CONTRIBUTING.md

@@ -0,0 +1,20 @@
+# Contributing
+
+## What is the goal of this repo?
+
+This repository provides an arena for teams across the MetaMask engineering department to share, discuss, and record principles, practices, and patterns for building, maintaining, and releasing products and libraries within the MetaMask ecosystem in a unified fashion. Keeping this knowledge has three intended benefits:
+
+- All contributors should be able to make changes to any part of MetaMask more easily.
+- MetaMask teams should be able to ship code faster.
+- The level of code quality within the MetaMask ecoystem should increase.
+
+## What sort of documentation goes in this repo?
+
+Anything is eligible for inclusion in this repository if:
+
+- it could benefit a significant subset of MetaMask
+- it is safe to share publicly
+
+## How do I contribute?
+
+Although parts of this repository were written by certain teams, the goal is for it to be useful to everyone in some way. If you see something missing from this documentation or have a different opinion on anything that may already exist, please feel free to open a pull request.

README.md

@@ -2,7 +2,7 @@
 
 Welcome! Here you can find the principles, policies, and practices which are followed by MetaMask engineers in building MetaMask. These resources are designed to enable all builders, whether internal or external, in making meaningful contributions to any part of the MetaMask ecosystem.
 
-This is a living repository — nothing is set in stone! If there is a change you want to introduce, feel free to start a discussion in an issue or propose the change itself in a pull request.
+This is a living repository — nothing is set in stone! If you're member of MetaMask and are interested in making updates to this repository, make sure to consult the [Contributing](./CONTRIBUTING.md) guide.
 
 ## Table of Contents
 

docs/engineering-principles.md

@@ -1,50 +1,52 @@
 # Engineering Principles
+
 Engineering principles define the core tenets and beliefs that the engineering team and all contributors are expected to keep front of mind. These tenets are meant to reflect the values of the organization.
 
 ## Core Engineering Values
-These are the qualities that we strive for in our software. (These values aren't ranked, but are all of equal importance.)
 
-* Security
-* Stability
-* Privacy
-* Maintainability
-* Usability
-* Transparency
+These are the qualities that we strive for in our software. (These values aren't ranked, but are all of equal importance.)
 
+- Security
+- Stability
+- Privacy
+- Maintainability
+- Usability
+- Transparency
 
 ## Principles
+
 ### The Principle of Least Authority
 
-Provide application code the absolute minimal amount of authority required to perform its essential functions. Wherever appropriate, break down large methods with broad authority into smaller functions with minimal authority. Minimizing what a method *can* do reduces the scope of what could possibly go wrong. When something does go wrong, small, isolated methods, written with the least amount of authority required, are easier to troubleshoot.
+Provide application code the absolute minimal amount of authority required to perform its essential functions. Wherever appropriate, break down large methods with broad authority into smaller functions with minimal authority. Minimizing what a method _can_ do reduces the scope of what could possibly go wrong. When something does go wrong, small, isolated methods, written with the least amount of authority required, are easier to troubleshoot.
 
 ### The Principle of Incremental Change
 
 To minimize the risk to the stability and security of the application, changes to the code should be incremental and as small as possible. Large changes to the codebase become difficult to review effectively and make the commit history less itemized. Furthermore, incremental change promotes better test coverage and makes it easier to require tests to cover the introduced changes.
 
 ### The Principle of Incremental Decentralization
 
-We are trying to build a decentralized future and we must make choices that move us directionally towards those goals. This means that users should be able to swap centralized services out for decentralized alternatives. Additionally, when we build features that rely upon centralized services we must build them in such a way where the experience isn't completely broken when the service is disrupted. 
+We are trying to build a decentralized future and we must make choices that move us directionally towards those goals. This means that users should be able to swap centralized services out for decentralized alternatives. Additionally, when we build features that rely upon centralized services we must build them in such a way where the experience isn't completely broken when the service is disrupted.
 
 ### The Principle of Self-Sovereign Identity
 
 We believe in the right of our users to own their own identity and data. We must go to great lengths to protect that right. Where we have features or services that might infringe upon that right, we must treat those features as opt-in, not opt-out. When we do build features that make user data known to us, we must not collect any personally identifiable information, and any data that can be tied to any chain must be collected in an anonymity-protecting way. This principle must be extended to cover all third-party code as well.
 
 ### The Principle of Auditability
 
-As we are committed to providing a high level of security and privacy within our product, we must also maintain an auditable, publically accessible, and transparent codebase. We mustn't ask our users to trust our products implicitly, but instead, write code that explicitly illustrates our values. In order for our codebase to be easily auditable, our code must have the following qualities: 
+As we are committed to providing a high level of security and privacy within our product, we must also maintain an auditable, publically accessible, and transparent codebase. We mustn't ask our users to trust our products implicitly, but instead, write code that explicitly illustrates our values. In order for our codebase to be easily auditable, our code must have the following qualities:
 
 1. Readability - Our code should be easily read, and be free of obfuscation or subterfuge.
-2. Consistency - Our code should follow consistent standards to assist auditors in tracing code paths across multiple repositories or code from varying authors. 
+2. Consistency - Our code should follow consistent standards to assist auditors in tracing code paths across multiple repositories or code from varying authors.
 3. Usability - Our code must maintain a standard of high quality and usability, and reflect the qualities listed in the values section above.
 4. Traceability - Our code should have a public record of changes made, with details about why the change was made.
 
 ### The Principle of "Be Methodical and Fix Things"
 
-We should prioritize fixing bugs and improving stability over creating new features whenever possible. All code generates new bugs and builds technical debt, this is inevitable. However, if we focus on building our features with stability in mind and throw out the "Move Fast and Break Things" mentality of most web 2.0 applications we can minimize the amount of bugs we introduce. Furthermore, whenever bugs are known to exist we should expend the necessary energy to remedy them. 
+We should prioritize fixing bugs and improving stability over creating new features whenever possible. All code generates new bugs and builds technical debt, this is inevitable. However, if we focus on building our features with stability in mind and throw out the "Move Fast and Break Things" mentality of most web 2.0 applications we can minimize the amount of bugs we introduce. Furthermore, whenever bugs are known to exist we should expend the necessary energy to remedy them.
 
 ### The Principle of Reliability
 
-We provide a plethora of features in our applications that users expect to be supported, and that they rely upon for their day-to-day activities. We must handle feature deprecation gracefully, and inform users well in advance that a feature is being sunsetted or replaced. If we remove features or experiences from our product without warning it will alienate our users and cause them to seek out other solutions. 
+We provide a plethora of features in our applications that users expect to be supported, and that they rely upon for their day-to-day activities. We must handle feature deprecation gracefully, and inform users well in advance that a feature is being sunsetted or replaced. If we remove features or experiences from our product without warning it will alienate our users and cause them to seek out other solutions.
 
 We also provide external facing APIs that app developers utilize to build their products. Every change we make to these APIs must be analyzed for potentially breaking functionality of the apps in our ecosystem. When we make breaking changes we are creating work for countless other organizations and individuals, and only by their good graces will they make the requested changes. We must view these breaking changes as a potential reset of our momentum within the ecosystem. Breaking changes should only be made for critical reasons of security or stability that cannot be made by any other means.