Merge branch 'main' into validate-watchAsset-nft-type

.github/pull_request_template.md

@@ -1,46 +1,52 @@
-## Description
+## Explanation
 
 <!--
 Thanks for your contribution! Take a moment to answer these questions so that reviewers have the information they need to properly understand your changes:
 
 * What is the current state of things and why does it need to change?
 * What is the solution your changes offer and how does it work?
-* What packages are you updating?
-* Are you introducing a breaking change to a package (renaming or removing a part of a public interface)?
+* Are there any changes whose purpose might not obvious to those unfamiliar with the domain?
+* If your primary goal was to update one package but you found you had to update another one along the way, why did you do so?
+* If you had to upgrade a dependency, why did you do so?
 -->
 
-## Changes
+## References
 
 <!--
-Pretend that you're updating a changelog. How would you categorize your changes?
+Are there any issues that this pull request is tied to? Are there other links that reviewers should consult to understand these changes better?
+
+For example:
+
+* Fixes #12345
+* Related to #67890
+-->
+
+## Changelog
+
+<!--
+If you're making any consumer-facing changes, list those changes here as if you were updating a changelog, using the template below as a guide.
+
+(CATEGORY is one of BREAKING, ADDED, CHANGED, DEPRECATED, REMOVED, or FIXED. For security-related issues, follow the Security Advisory process.)
 
-CATEGORY is one of:
+Please take care to name the exact pieces of the API you've added or changed (e.g. types, interfaces, functions, or methods).
 
-- BREAKING
-- ADDED
-- CHANGED
-- DEPRECATED
-- REMOVED
-- FIXED
+If there are any breaking changes, make sure to offer a solution for consumers to follow once they upgrade to the changes.
 
-(Security-related changes should go through the Security Advisory process.)
+Finally, if you're only making changes to development scripts or tests, you may replace the template below with "None".
 -->
 
-- **<CATEGORY>**: Your change here
+### `@metamask/package-a`
+
 - **<CATEGORY>**: Your change here
 - **<CATEGORY>**: Your change here
 
-## References
-
-<!--
-Are there any issues or other links that reviewers should consult to understand this pull request better? For instance:
+### `@metamask/package-b`
 
-* Fixes #12345
-* See: #67890
--->
+- **<CATEGORY>**: Your change here
+- **<CATEGORY>**: Your change here
 
 ## Checklist
 
 - [ ] I've updated the test suite for new or updated code as appropriate
-- [ ] I've updated documentation for new or updated code as appropriate (note: this will usually be JSDoc)
+- [ ] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
 - [ ] I've highlighted breaking changes using the "BREAKING" category above as appropriate

.github/workflows/lint-build-test.yml

@@ -40,7 +40,7 @@ jobs:
         with:
           node-version: ${{ matrix.node-version }}
           cache: yarn
-      - run: yarn --immutable --immutable-cache
+      - run: yarn --immutable
       - run: yarn lint
       - name: Require clean working directory
         shell: bash
@@ -65,7 +65,7 @@ jobs:
         with:
           node-version: ${{ matrix.node-version }}
           cache: yarn
-      - run: yarn --immutable --immutable-cache
+      - run: yarn --immutable
       - run: yarn workspace ${{ matrix.package-name }} changelog:validate
       - name: Require clean working directory
         shell: bash
@@ -89,7 +89,7 @@ jobs:
         with:
           node-version: ${{ matrix.node-version }}
           cache: yarn
-      - run: yarn --immutable --immutable-cache
+      - run: yarn --immutable
       - run: yarn build
       - name: Require clean working directory
         shell: bash
@@ -114,7 +114,7 @@ jobs:
         with:
           node-version: ${{ matrix.node-version }}
           cache: yarn
-      - run: yarn --immutable --immutable-cache
+      - run: yarn --immutable
       - run: yarn workspace ${{ matrix.package-name }} run test
       - name: Require clean working directory
         shell: bash

docs/contributing.md

@@ -18,6 +18,39 @@
 >
 > `workspaceName` in these commands is the `name` field within a package's `package.json`, e.g., `@metamask/address-book-controller`, not the directory where it is located, e.g., `packages/address-book-controller`.
 
+## Linting
+
+Run `yarn lint` to lint all files and show possible violations.
+
+Run `yarn lint:fix` to fix any automatically fixable violations.
+
+## Performing operations across the monorepo
+
+This repository relies on Yarn's [workspaces feature](https://yarnpkg.com/features/workspaces) to provide a way to work with packages individually and collectively. Refer to the documentation for the following Yarn commands for usage instructions:
+
+- [`yarn workspace`](https://yarnpkg.com/cli/workspace)
+- [`yarn workspaces foreach`](https://yarnpkg.com/cli/workspaces/foreach)
+
+> **Note**
+>
+> - `workspaceName` in the Yarn documentation is the `name` field within a package's `package.json`, e.g., `@metamask/address-book-controller`, not the directory where it is located, e.g., `packages/address-book-controller`.
+> - `commandName` in the Yarn documentation is any sub-command that the `yarn` executable would usually take. Pay special attention to the difference between `run` vs `exec`. If you want to run a package script, you would use `run`, e.g., `yarn workspace @metamask/address-book-controller run changelog:validate`; but if you want to run _any_ shell command, you'd use `exec`, e.g. `yarn workspace @metamask/address-book-controller exec cat package.json | jq '.version'`.
+
+## Creating pull requests
+
+When submitting a pull request for this repo, take some a bit of extra time to fill out its description. Use the provided template as a guide, paying particular attention to two sections:
+
+- **Explanation**: This section is targeted toward maintainers and is intended for you to explain the purpose and scope of your changes and share knowledge that they might not be able to see from reading the PR alone. Some questions you should seek to answer are:
+  - What is the motivator for these changes? What need are the changes satisfying? Is there a ticket you can share or can you provide some more context for people who might not be familiar with the domain?
+  - Are there any changes in particular whose purpose might not be obvious or whose implementation might be difficult to decipher? How do they work?
+  - If your primary goal was to update one package but you found you had to update another one along the way, why did you do so?
+  - If you had to upgrade a dependency, why did you do so?
+- **Changelog:** This section is targeted toward consumers — internal developers of the extension or mobile app in addition to external dapp developers — and is intended to be a list of your changes from the perspective of each package in the monorepo. Questions you should seek to answer are:
+  - Which packages are being updated?
+  - What are the _exact_ changes to the API (types, interfaces, functions, methods) that are being changed?
+  - What are the anticipated effects to whichever platform might want to make use of these changes?
+  - If there are breaking changes to the API, what do consumers need to do in order to adapt to those changes upon upgrading to them?
+
 ## Using packages in other projects during development/testing
 
 When developing changes to packages within this repository that a different project depends upon, you may wish to load those changes into the project and test them locally or in CI before publishing proper releases of those packages. To solve that problem, this repository provides a mechanism to publish "preview" versions of packages to GitHub Package Registry. These versions can then be used in the project like any other version, provided the project is configured to use that registry.
@@ -101,24 +134,6 @@ If you're a contributor and you've forked this repository, you can create previe
 6. If you make any new changes to your project, repeat steps 3-5 to generate and use new preview versions.
 7. As changes will have been made to this repository (due to step 4), make sure to clear out those changes after you've completed testing.
 
-## Linting
-
-Run `yarn lint` to lint all files and show possible violations.
-
-Run `yarn lint:fix` to fix any automatically fixable violations.
-
-## Performing operations across the monorepo
-
-This repository relies on Yarn's [workspaces feature](https://yarnpkg.com/features/workspaces) to provide a way to work with packages individually and collectively. Refer to the documentation for the following Yarn commands for usage instructions:
-
-- [`yarn workspace`](https://yarnpkg.com/cli/workspace)
-- [`yarn workspaces foreach`](https://yarnpkg.com/cli/workspaces/foreach)
-
-> **Note**
->
-> - `workspaceName` in the Yarn documentation is the `name` field within a package's `package.json`, e.g., `@metamask/address-book-controller`, not the directory where it is located, e.g., `packages/address-book-controller`.
-> - `commandName` in the Yarn documentation is any sub-command that the `yarn` executable would usually take. Pay special attention to the difference between `run` vs `exec`. If you want to run a package script, you would use `run`, e.g., `yarn workspace @metamask/address-book-controller run changelog:validate`; but if you want to run _any_ shell command, you'd use `exec`, e.g. `yarn workspace @metamask/address-book-controller exec cat package.json | jq '.version'`.
-
 ## Releasing
 
 The [`create-release-branch`](https://github.com/MetaMask/create-release-branch) tool and [`action-publish-release`](https://github.com/MetaMask/action-publish-release) GitHub action are used to automate the release process.

package.json

@@ -1,6 +1,6 @@
 {
   "name": "@metamask/core-monorepo",
-  "version": "55.0.0",
+  "version": "60.0.0",
   "private": true,
   "description": "Monorepo for packages shared between MetaMask clients",
   "repository": {

packages/approval-controller/CHANGELOG.md

@@ -6,6 +6,17 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [3.3.0]
+### Added
+- Add `setFlowLoadingText` method to ApprovalController ([#1419](https://github.com/MetaMask/core/pull/1419))
+
+## [3.2.0]
+### Added
+- Add `startFlow` and `endFlow` methods to ApprovalController ([#1394](https://github.com/MetaMask/core/pull/1394))
+
+### Fixed
+- Fix ApprovalController constructor so that it accepts a messenger created by calling `getRestricted` without having type parameters explicitly specified ([#1417](https://github.com/MetaMask/core/pull/1417))
+
 ## [3.1.0]
 ### Added
 - Optional feedback when accepting an approval request ([#1396](https://github.com/MetaMask/core/pull/1396))
@@ -48,7 +59,9 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
     All changes listed after this point were applied to this package following the monorepo conversion.
 
-[Unreleased]: https://github.com/MetaMask/core/compare/@metamask/approval-controller@3.1.0...HEAD
+[Unreleased]: https://github.com/MetaMask/core/compare/@metamask/approval-controller@3.3.0...HEAD
+[3.3.0]: https://github.com/MetaMask/core/compare/@metamask/approval-controller@3.2.0...@metamask/approval-controller@3.3.0
+[3.2.0]: https://github.com/MetaMask/core/compare/@metamask/approval-controller@3.1.0...@metamask/approval-controller@3.2.0
 [3.1.0]: https://github.com/MetaMask/core/compare/@metamask/approval-controller@3.0.0...@metamask/approval-controller@3.1.0
 [3.0.0]: https://github.com/MetaMask/core/compare/@metamask/approval-controller@2.1.1...@metamask/approval-controller@3.0.0
 [2.1.1]: https://github.com/MetaMask/core/compare/@metamask/approval-controller@2.1.0...@metamask/approval-controller@2.1.1

packages/approval-controller/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@metamask/approval-controller",
-  "version": "3.1.0",
+  "version": "3.3.0",
   "description": "Manages requests that require user approval",
   "keywords": [
     "MetaMask",