Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migrate json rpc engine repo #1804

Closed
wants to merge 206 commits into from
Closed

Conversation

kanthesha
Copy link
Contributor

Explanation

We would like to migrate most MetaMask libraries into core monorepo to make them easier to maintain.

In this PR, we are migrating json-rpc-engine into core monorepo. In the process of migration, we don't want to remove / loose the original GIT history, but to preserve the history of the library as though the entire project had been located in a merged-packages/json-rpc-engine directory all along.

We chose to place json-rpc-engine initially in the merged-packages and not packages so we can hide it from Yarn, ESLint, Prettier, and TypeScript. This allows us to clean it up and conform it to how we've configured this repo before we properly incorporate it.

References

Fixes https://app.zenhub.com/workspaces/shared-libraries-621e46b4d7103800171d1b02/issues/gh/metamask/core/1550

Changelog

metamask/json-rpc-engine

  • Migration: migrating json-rpc-engine to core monorepo

Checklist

  • I've updated the test suite for new or updated code as appropriate
  • 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

@socket-security
Copy link

socket-security bot commented Oct 11, 2023

🚨 Potential security issues detected. Learn more about Socket for GitHub ↗︎

To accept the risk, merge this PR and you will not be notified again.

Issue Package Version Note Source
New author react-is 18.2.0
New author unique-slug 3.0.0
New author @npmcli/run-script 6.0.1
New author @npmcli/fs 2.1.2

Next steps

What is new author?

A new npm collaborator published a version of the package for the first time. New collaborators are usually benign additions to a project, but do indicate a change to the security surface area of a package.

Scrutinize new collaborator additions to packages because they now have the ability to publish code into your dependency tree. Packages should avoid frequent or unnecessary additions or changes to publishing rights.

Take a deeper look at the dependency

Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support [AT] socket [DOT] dev.

Remove the package

If you happen to install a dependency that Socket reports as Known Malware you should immediately remove it and select a different dependency. For other alert types, you may may wish to investigate alternative packages or consider if there are other ways to mitigate the specific risk posed by the dependency.

Mark a package as acceptable risk

To ignore an alert, reply with a comment starting with @SocketSecurity ignore followed by a space separated list of package-name@version specifiers. e.g. @SocketSecurity ignore foo@1.0.0 bar@* or ignore all packages with @SocketSecurity ignore-all

  • @SocketSecurity ignore react-is@18.2.0
  • @SocketSecurity ignore unique-slug@3.0.0
  • @SocketSecurity ignore @npmcli/run-script@6.0.1
  • @SocketSecurity ignore @npmcli/fs@2.1.2

@kanthesha kanthesha marked this pull request as ready for review October 11, 2023 15:05
@kanthesha kanthesha requested a review from a team as a code owner October 11, 2023 15:05
@MajorLift
Copy link
Contributor

I think applying the the core monorepo eslint config and seeing if anything breaks should ideally happen alongside the eslint package version bumps, but as long as it's done before the files are moved into packages/ there shouldn't be any issues.

MajorLift
MajorLift previously approved these changes Oct 11, 2023
@legobeat
Copy link
Contributor

legobeat commented Oct 12, 2023

I think applying the the core monorepo eslint config and seeing if anything breaks should ideally happen alongside the eslint package version bumps, but as long as it's done before the files are moved into packages/ there shouldn't be any issues.

Perhaps this can be done in https://github.com/MetaMask/json-rpc-engine prior to actually migrating? What is outstanding after MetaMask/json-rpc-engine#169 ?

@legobeat
Copy link
Contributor

Has an assessment be made as how to proceed with MetaMask/json-rpc-engine#81 ?

@MajorLift
Copy link
Contributor

Perhaps this can be done in https://github.com/MetaMask/json-rpc-engine prior to actually migrating?

@legobeat Yes this can definitely be done in the original repo. I have it as the very first step in the package migration checklist I'm putting together.

@mcmire
Copy link
Contributor

mcmire commented Oct 12, 2023

I think we should hold on this until 1) we've successfully migrated eth-json-rpc-provider (and thus we have a complete migration checklist created) and 2) we've addressed any tickets for json-rpc-engine we can complete prior to migration.

@mcmire
Copy link
Contributor

mcmire commented Oct 13, 2023

Has an assessment be made as how to proceed with MetaMask/json-rpc-engine#81 ?

Great question. I know this PR has been sitting around for a while. I will try to make some time tomorrow to think more about this PR. Perhaps it is not as consequential as I imagine.

@kanthesha
Copy link
Contributor Author

I think applying the the core monorepo eslint config and seeing if anything breaks should ideally happen alongside the eslint package version bumps, but as long as it's done before the files are moved into packages/ there shouldn't be any issues.

@MajorLift The eslint config has already been applied similar to core monorepo, it's here. Just wondering, you see something missing ?

@MajorLift
Copy link
Contributor

MajorLift commented Oct 17, 2023

@kanthesha Yes, so aside from aligning the package versions, we also need to align json-rpc-engine's eslint rules with the monorepo, and fix any linter warnings/errors resulting from introducing those new rules.

This is achieved by replacing the .eslintrc.js file of this library with the corresponding file from the root directory of the core monorepo, and running yarn lint:fix.

Here's the relevant PR in the eth-json-rpc-provider source repo: https://github.com/MetaMask/eth-json-rpc-provider/pull/28/files#diff-e2954b558f2aa82baff0e30964490d12942e0e251c1aa56c3294de6ec67b7cf5

kanthesha and others added 5 commits October 18, 2023 19:17
* applied eslint rules from core monorepo and fixed the errors

* added eslint-import-resolver-typescript devDependencies
* 7.2.0

* release notes modified in changelog

---------

Co-authored-by: github-actions <github-actions@github.com>
Co-authored-by: Kanthesha Devaramane <kanthesha.devaramane@consensys.net>
@kanthesha kanthesha marked this pull request as ready for review October 19, 2023 12:48
@MajorLift
Copy link
Contributor

Would you be able to clear up the merge commits from main in the commit history here? @mcmire pointed out that they make the history harder to read if you're looking at a tree view of the history. I added this to the checklist but forgot to communicate it to you, sorry about that.

You could either do a manual cleanup and force push or just do the git filter-repo process again on a new branch and replace this PR branch with it. Rebasing won't work, unfortunately, because we want to preserve the original git history.

For future migrations, we hope to avoid this issue by coordinating with the team to review and close the git history migration PRs ASAP without leaving them open for long.

@mcmire
Copy link
Contributor

mcmire commented Oct 19, 2023

@kanthesha:

For context behind @MajorLift's request, we were trying to figure out why the link for the "Unreleased" header for eth-json-rpc-provider showed sooo many commits, and in order to investigate this I had to look at a tree view (I've been using Sourcetree). Usually the tree view for main is pretty clean because we Squash and Merge commits:

Screenshot 2023-10-19 at 11 32 13 AM

But since we've been using merge commits for these library migrations, it has the potential to make the tree view more complex. This complexity makes it more difficult to understand the history and especially locate the branch in the library repo that we are merging with the core monorepo branch. For instance, it creates a view like this. This complexity is created by the merge commits introduced in a previous PR that are now recorded in history:

Screenshot 2023-10-19 at 11 25 15 AM

Obviously we're not going to be able to get rid of all merge commits. For a library migration branch such as this very one, it's inevitable that as changes are made to core, we will have to keep that branch up to date, and that will introduce those kinds of commits. But, as @MajorLift said, if we try to get this branch merged faster, then it reduces the number that stick around after the branch is merged.

Anyway, when you've re-run filter-repo on an updated branch as @MajorLift has suggested, I can try to keep a better eye on this PR so it's not sitting around so long.

@kanthesha
Copy link
Contributor Author

kanthesha commented Oct 19, 2023

Got it, thanks for the detailed explanation @mcmire .
I think, the easiest way is to just create a new one altogether. I'll do that now.

@kanthesha
Copy link
Contributor Author

kanthesha commented Oct 19, 2023

It is available in the new PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.