-
-
Notifications
You must be signed in to change notification settings - Fork 187
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
deps: Bump @metamask/{eth-json-rpc-provider,rpc-errors}
#1653
Conversation
New dependencies detected. Learn more about Socket for GitHub ↗︎
|
@metamask/{eth-json-rpc-provider,rpc-errors,utils}
bc0d221
to
5972103
Compare
5972103
to
4610873
Compare
3bc848a
to
f530b96
Compare
👍 Dependency issues cleared. Learn more about Socket for GitHub ↗︎ This PR previously contained dependency changes with security issues that have been resolved, removed, or ignored. |
new author ok (known version) |
f530b96
to
f081410
Compare
unstable ownership ok |
9161c19
to
91e5cfa
Compare
…PollingBlockTracker to type BlockTracker
This reverts commit bc269f5.
Co-authored-by: Elliot Winkler <elliot.winkler@gmail.com>
942a8e7
to
d80a8d7
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great! Merge away 💪🏻
@@ -13,10 +13,9 @@ export class FakeBlockTracker extends PollingBlockTracker { | |||
super({ | |||
provider: new SafeEventEmitterProvider({ engine: new JsonRpcEngine() }), | |||
}); | |||
} | |||
|
|||
override async _start() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm wondering if we can solve this the same way that I want to solve the fake provider — that is, instead of extending from a block tracker class, have a class that fulfills the block tracker interface. You're right that that would be a separate change though. This is fine for now — thanks for clarifying.
--------- Co-authored-by: Elliot Winkler <elliot.winkler@gmail.com>
--------- Co-authored-by: Elliot Winkler <elliot.winkler@gmail.com>
@@ -6957,7 +6957,7 @@ function buildFakeClient( | |||
rpcUrl: 'https://test.network', | |||
}, | |||
provider, | |||
blockTracker: new FakeBlockTracker(), | |||
blockTracker: new FakeBlockTracker() as BlockTracker, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MajorLift This is an example of us needing to use a type assertion. I guess the type of FakeBlockTracker
isn't quite right here and doesn't match the type of blockTracker
that NetworkClient
demands.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mcmire This seems like it's either been fixed or wasn't needed in the first place: #1833. These silent false negatives are the worse thing about type assertions IMO.
In general, when encountering "not assignable to" errors, I would like the underlying types to be reconciled/aligned, at least eventually. Are there maybe "usual suspect" entities in our codebase that I can assume it'll be safe to use type assertion on?
## Explanation This PR implements the following incremental steps in the process for migrating `eth-json-rpc-provider` into the core monorepo: *** ### Phase B: Staging from `merged-packages/` #### 5. Port tags - See: #1800 <details> <summary>Push ported tags to core repo</summary> - [x] https://github.com/MetaMask/core/releases/tag/@metamask/eth-json-rpc-provider@2.2.0 - [x] https://github.com/MetaMask/core/releases/tag/@metamask/eth-json-rpc-provider@2.1.0 - [x] https://github.com/MetaMask/core/releases/tag/@metamask/eth-json-rpc-provider@2.0.0 - [x] https://github.com/MetaMask/core/releases/tag/@metamask/eth-json-rpc-provider@1.0.1 - [x] https://github.com/MetaMask/core/releases/tag/@metamask/eth-json-rpc-provider@1.0.0 </details> <details> <summary>Verify that the tag diff links in CHANGELOG are working</summary> - [x] **WONTFIX**: https://github.com/MetaMask/core/compare/@metamask/eth-json-rpc-provider@2.2.0...HEAD - [x] https://github.com/MetaMask/core/compare/@metamask/eth-json-rpc-provider@2.1.0...@metamask/eth-json-rpc-provider@2.2.0 - [x] https://github.com/MetaMask/core/compare/@metamask/eth-json-rpc-provider@2.0.0...@metamask/eth-json-rpc-provider@2.1.0 - [x] https://github.com/MetaMask/core/compare/@metamask/eth-json-rpc-provider@1.0.1...@metamask/eth-json-rpc-provider@2.0.0 - [x] https://github.com/MetaMask/core/compare/@metamask/eth-json-rpc-provider@1.0.0...@metamask/eth-json-rpc-provider@1.0.1 </details> ### Phase C: Integration into `packages/` #### 1. The big leap - [x] **Move migration target from `migrated-packages/` to `packages/`.** - [x] Run `yarn install` in the root directory. - [x] Check that all tests are passing in migration target by running `yarn workspace @metamask/<package-name> test`. #### 2. Update downstream repos - [x] Add tsconfig reference paths for migration target in downstream packages and root. - [x] Bump migration target version in downstream packages and root. #### 3. Linter fixes - [x] Apply yarn constraints fixes to migration target package.json file: `yarn constraints --fix` (run twice). - [x] Identify validator fixes for CHANGELOG using `yarn workspace @metamask/<package-name> changelog:validate` and apply the diffs. #### 4. Resolve downstream errors - [x] #1653 - If introducing the migration target breaks any downstream repos: - [x] Resolve simple errors - [x] Mark and ignore complex errors using `@ts-expect-error TODO:` annotations. - [x] Create a separate issue for resolving the marked errors as soon as the migration is completed. #### 5. Finalize merge - [x] Check that all tests are passing in all subpackages of core and CI. - [x] Merge `packages/<package-name>` directory into core main branch. *** See #1551 (comment) for an outline of the entire process. ## Next Steps - The next PR(s) will implement the final steps of the migration process (D-1 in the migration checklist). ## Blocked by - Dependencies: - [x] typescript bump: #1718 - [x] `@metamask/utils` bump: #1639 - Downstream type errors: - [x] #1653 - [ ] MetaMask/eth-json-rpc-provider#14 (ignored) - [ ] MetaMask/utils#140 (ignored) - Tag porting: - [x] #1802 - [x] "Unreleased" tag diff link shows entire history of core: https://github.com/MetaMask/core/compare/@metamask/eth-json-rpc-provider@2.2.0...HEAD ## References - Contributes to #1685 - Contributes to #1551 ## 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.) Please take care to name the exact pieces of the API you've added or changed (e.g. types, interfaces, functions, or methods). If there are any breaking changes, make sure to offer a solution for consumers to follow once they upgrade to the changes. Finally, if you're only making changes to development scripts or tests, you may replace the template below with "None". --> ### `@metamask/eth-json-rpc-provider` - **ADDED**: Migrated into the core monorepo. ## Checklist - [x] I've updated the test suite for new or updated code as appropriate - [x] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate - [x] I've highlighted breaking changes using the "BREAKING" category above as appropriate
Explanation
Combination of:
References
Blocked by
clone
withklona
eth-json-rpc-middleware#250@metamask/eslint-config*
from v9 to^12.1.0
eth-json-rpc-infura#90Blocking