Fully migrate eth-json-rpc-provider into core monorepo

[xinnanyemm]

We would like to migrate the @metamask/eth-json-rpc-provider library into this repo to make it easier to maintain.

See the following checklist for instructions on accomplishing this: #1551 (comment)

[MajorLift]

Migration Checklist

Phase A: Preparation in source repo

1. Add migration notice to README

• Add migration notice to README eth-json-rpc-provider#38

<table><tr><td><p align="center"><b>⚠️ PLEASE READ ⚠️</b></p><p align="center">This package is currently being migrated to our <a href="https://github.com/MetaMask/core"><code>core</code></a> monorepo. Please do not make any commits to this repository while this migration is taking place, as they will not be transferred over. Also, please re-open PRs that are under active development in the core repo.</p></td></tr></table>

2. Disable dependabot dependency upgrades.

3. Add source repo to ZenHub workspace repo filter so that issues/PRs show up on the board.

4. Align TypeScript, ESLint, Prettier dependency versions and configurations with the core monorepo.

• Align ESLint, Prettier packages and configs with core monorepo ahead of migration eth-json-rpc-provider#28
  • If migration target is ahead of core in dependency versions, consider updating core dependencies first.
  • Resolve all resulting issues.

5. Add any missing files required in subpackages of the core monorepo (e.g. LICENSE).

• Add missing ISC license information eth-json-rpc-provider#24

6. If the package name is not prefixed by the @metamask/ namespace, rename the package.

• Modify the "name" field in package.json.
• Update the title of the README.md.
• Add a CHANGELOG entry for the rename.

7. Create a new release of the migration target from the source repo

• 2.2.0 eth-json-rpc-provider#29
• All subsequent releases of migration target will be partial releases made from the core monorepo.

---

Phase B: Staging from merged-packages/

0. Move the migration target into a temporary directory in core (merged-packages/).

• Migrate eth-json-rpc-provider into core monorepo (1/2) #1755
  • Follow these instructions to ensure that the original git history remains fully intact after the transfer: Migrate libraries into core monorepo #1079 (comment).
  • MUST NOT rebase the migrate-<package-name> branch.
  • Ensure that superfluous merge commits don't pollute the history. If necessary, replace the PR branch with a cleaned-up post-migration commit history by rerunning the git history migration steps before merging the PR.
    • For context: Migrate json rpc engine repo #1804 (comment)
  • Contact admins to temporarily enable merge commits into main.
  • Merge PR without squashing to preserve the migrated git commit history.

1. Port tags

• See: Add script for tag porting when migrating libraries into the core monorepo #1800
  • Port the tags locally with the correct package name prefixes.
  • Push the ported tags to a fork of the core monorepo for testing.
  • Verify that the tag diff links in CHANGELOG are working.
  • The diff between last tag before migration and first one after will always include the entire history of the monorepo.
    • TODO: The correct diff can be derived using git log --ancestry-path. If GitHub starts supporting compare links that use --ancestry-path, the broken diff link in the changelog should be fixed.
  • Push the ported tags to the core repo.
  • Verify that the tag diff links in CHANGELOG are working.
  • Identify and create tags for release commits that were untagged in the original repo.

2. Remove files and directories that will be replaced by files in the monorepo root.

• eth-json-rpc-provider migration - B1: Remove redundant files and directories. #1764
  • Remove: .github/, .git*, scripts/, .depcheckrc.json, .yarn/, .yarnrc.yml, yarn.lock, .editorconfig, .eslint*, .prettier*, .nvm*.
  • Keep: src/, tests/, CHANGELOG.md, LICENSE, package.json, README.md, jest.config.js, tsconfig*.json, typedoc.json.

3. Replace config files.

• eth-json-rpc-provider migration - B2: Replace typescript, jest config files. #1765
  • Update tsconfig*.json, typedoc.json, jest.config.js to extend from corresponding files in root. Copy contents of corresponding files in other non-root packages.
  • Keep TypeScript compiler flags and compilation target.
  • Add tsconfig reference paths for non-root packages that are upstream dependencies of the migration target.
  • Keep Jest coverage threshold values.
  • Add deepmerge as a devDependency.

4. Align dependencies and build scripts with monorepo.

• eth-json-rpc-provider migration - B3: Align dependencies with monorepo. #1766
  • Remove redundant build scripts that are already listed in the root package.json (including prepack)
  • Identify validator fixes for CHANGELOG by navigating to merged-packages/<package-name>, running ../../scripts/validate-changelog.sh @metamask/<package-name>, and applying the diffs.
    • If the package has been renamed or needs to be renamed with the @metamask/ namespace, supply two arguments: versionBeforePackageRename, tagPrefixBeforePackageRename.
    • See https://github.com/MetaMask/auto-changelog#validate
  • Remove redundant dependencies that are already listed in the root package.json.
    • Exception: do not remove TypeScript.
  • Align dependency versions with other non-root packages.
    • If migration target dependency version is ahead: Decrement to match monorepo packages.
    • If it's behind:
      • Bump if it's an internal dependency (i.e. the dependency is another sub-package in the monorepo).
      • If it's external, bump only if there are no resulting breaking changes that need to be resolved.

5. Add exception for non-MIT license.

• add exception in the constraints.pro for non MIT license #1888
  • If migration target uses a non-MIT license, add exception entries in the root constraints.pro file.
    • Add 2 rules to license section of constraints.pro: Exclude (\=) from MIT rule and include in ISC rule (==)
  • Make sure the new rule doesn't break any of the existing package.json files by running yarn constraints.

6. Update README

• Update contents of migration target's README to reflect new status as a non-root package in the monorepo.
  • Preserve package intro sentence/paragraph.
  • Add/modify "Installation" section.
  • Preserve "Usage" section.
  • Remove "Test", "Build" and other instructions on common development tasks.
  • Add "Contributing" section.

---

Phase C: Integration into packages/

• eth-json-rpc-provider migration - Integration into packages/ #1738

1. The big leap

• Move migration target from merged-packages/ to packages/.
• Run yarn install in the root directory.
• Check that all tests are passing in migration target by running yarn workspace @metamask/<package-name> test.

2. Update downstream repos

• IMPORTANT Add reference paths for migration target in the root tsconfig.json and tsconfig.build.json files.
  • This step is essential to avoid build failure for the migration target during release workflow.
• Add tsconfig reference paths for migration target in downstream packages.
• Bump migration target version in downstream packages and root.
  • Notes on why this version bump needs to happen as part of this PR (import module shadowing): eth-json-rpc-provider migration - Integration into packages/ #1738 (comment)

3. Linter fixes

• Apply yarn constraints fixes to migration target package.json file: yarn constraints --fix (run twice).
• Add the changelog:validate build script.

4. Resolve or TODO downstream errors

• If introducing the migration target breaks any downstream repos:
  • Resolve simple errors
  • Mark and ignore complex/blocked errors using @ts-expect-error TODO: annotations.
• Create a separate issue for resolving the marked errors as soon as the migration is completed.
  • Fix provider type errors in NetworkController and its downstream packages #1823

5. Finalize merge

• Check that all tests are passing in all subpackages of core and CI.
• Double-check that dependency version bumps or other changes made to main while the PR was open are correctly merged and reflected.
• Merge packages/<package-name> directory into core main branch.

---

Phase D: Release and Clean-up

Source repo

• Transfer open issues from the source repo into the core monorepo using the Transfer issue feature.
  • Blocked by Explore solutions for transferring issues and PRs from other repos into the core monorepo #1835
  • Prepend the title with the package name.
• For open PRs in the source repo, lock conversation (with no reason provided), and leave a comment requesting that authors reopen the PR in core with a link pointing to the discussion in the original PR.
  • For important PRs, manually migrate into core or create tickets for follow-up.

This library has now been migrated into the [core monorepo](https://github.com/metamask/core/). This PR has been locked and this repo will be archived shortly. Going forward, releases of this library will only include changes made in the core repo.
- Please push this branch to core and open a new PR there.
- Optionally, add a link pointing to the discussion in this PR to provide context.

• Leave a note in the source repo's README announcing the migration and pointing to core.

<table><tr><td><p align="center"><b>⚠️ PLEASE READ ⚠️</b></p><p align="center">This package has been migrated to our <a href="https://github.com/MetaMask/core"><code>core</code></a> monorepo, and this repository has been archived. Please note that all future development and feature releases will take place in the <a href="https://github.com/MetaMask/core"><code>core</code></a> repository.</p></td></tr></table>

• Sunset GitHub Pages docs and leave link pointing to migrated docs in core.
• Archive the source repo to prevent any changes from being pushed to it going forward.

Core

• Add migration target to README dependency graph using the generate-dependency-graph build script.
• Fix downstream errors that were marked with @ts-expect-error TODO: during the migration process.
• Use the yarn create-release-branch tool to publish a release of core with a new version for the migrated package and any updated downstream packages.
  • Record any changes made to packages during the migration process in their respective CHANGELOGs.
• Publish typedocs with GitHub Pages.