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

The invalid type Record<never, never> removed from return type #4609

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

kanthesha
Copy link
Contributor

Explanation

The Record<never, never> type assigned to a response of convertEip1193RequestToJsonRpcRequest function does not belong here (link to the code), no possible return value is represented by that type.

References

Changelog

@metamask/eth-json-rpc-provider

  • FIXED: The invalid Record<never, never> type has been removed from response of convertEip1193RequestToJsonRpcRequest. And also type assignment simplified.

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

@kanthesha kanthesha marked this pull request as ready for review August 14, 2024 12:13
@kanthesha kanthesha requested a review from a team as a code owner August 14, 2024 12:13
Copy link
Contributor

@MajorLift MajorLift left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Making these methods non-generic doesn't seem like a viable option to me. Instead, I think we should allocate more time to finding solutions for the type issues here.

async request<Params extends JsonRpcParams, Result extends Json>(
eip1193Request: Eip1193Request<Params>,
): Promise<Result> {
async request(eip1193Request: Eip1193Request): Promise<Json> {
Copy link
Contributor

@MajorLift MajorLift Aug 14, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't request still be generic over Params and Result? This seems like a fundamental alteration of the EIP-1193 provider API that would make it unusable in many downstream call sites.

We should check whether this change breaks downstream packages using a preview build of this branch.

Comment on lines +29 to +31
export function convertEip1193RequestToJsonRpcRequest(
eip1193Request: Eip1193Request,
): JsonRpcRequest {
Copy link
Contributor

@MajorLift MajorLift Aug 14, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above, I think this function needs to be generic over Params. It would potentially be unusable downstream without an exposed way to narrow the params property of the return object.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In EIP 1193 optional params is unknown[] | object. And here we have assigned the same using JsonRpcParams (it's a default type for params). So it has to be of this type. Just thinking, in which case we need this to be beyond this type?

@MajorLift
Copy link
Contributor

MajorLift commented Aug 14, 2024

Record<never, never> is useful as the only way to represent an empty type object. The never index signature ensures that no property can be assigned to this type object.

  • The {} type is not an alternative, because it means NonNullable<unknown> instead of "empty object".
  • never is not an alternative, because any Record type is wider than the empty union.

That said, I agree that it's probably not being used correctly in this case.

@MajorLift
Copy link
Contributor

@metamaskbot publish-preview

Copy link
Contributor

Preview builds have been published. See these instructions for more information about preview builds.

Expand for full list of packages and versions.
{
  "@metamask-previews/accounts-controller": "18.0.0-preview-1e84326",
  "@metamask-previews/address-book-controller": "5.0.0-preview-1e84326",
  "@metamask-previews/announcement-controller": "7.0.0-preview-1e84326",
  "@metamask-previews/approval-controller": "7.0.2-preview-1e84326",
  "@metamask-previews/assets-controllers": "37.0.0-preview-1e84326",
  "@metamask-previews/base-controller": "6.0.2-preview-1e84326",
  "@metamask-previews/build-utils": "3.0.0-preview-1e84326",
  "@metamask-previews/chain-controller": "0.1.1-preview-1e84326",
  "@metamask-previews/composable-controller": "7.0.0-preview-1e84326",
  "@metamask-previews/controller-utils": "11.0.2-preview-1e84326",
  "@metamask-previews/ens-controller": "13.0.1-preview-1e84326",
  "@metamask-previews/eth-json-rpc-provider": "4.1.3-preview-1e84326",
  "@metamask-previews/gas-fee-controller": "19.0.1-preview-1e84326",
  "@metamask-previews/json-rpc-engine": "9.0.2-preview-1e84326",
  "@metamask-previews/json-rpc-middleware-stream": "8.0.2-preview-1e84326",
  "@metamask-previews/keyring-controller": "17.1.2-preview-1e84326",
  "@metamask-previews/logging-controller": "5.0.0-preview-1e84326",
  "@metamask-previews/message-manager": "10.0.2-preview-1e84326",
  "@metamask-previews/name-controller": "8.0.0-preview-1e84326",
  "@metamask-previews/network-controller": "20.1.0-preview-1e84326",
  "@metamask-previews/notification-controller": "6.0.0-preview-1e84326",
  "@metamask-previews/notification-services-controller": "0.2.1-preview-1e84326",
  "@metamask-previews/permission-controller": "11.0.0-preview-1e84326",
  "@metamask-previews/permission-log-controller": "3.0.0-preview-1e84326",
  "@metamask-previews/phishing-controller": "10.1.1-preview-1e84326",
  "@metamask-previews/polling-controller": "9.0.1-preview-1e84326",
  "@metamask-previews/preferences-controller": "13.0.1-preview-1e84326",
  "@metamask-previews/profile-sync-controller": "0.2.1-preview-1e84326",
  "@metamask-previews/queued-request-controller": "4.0.0-preview-1e84326",
  "@metamask-previews/rate-limit-controller": "6.0.0-preview-1e84326",
  "@metamask-previews/selected-network-controller": "17.0.0-preview-1e84326",
  "@metamask-previews/signature-controller": "18.0.1-preview-1e84326",
  "@metamask-previews/transaction-controller": "35.1.1-preview-1e84326",
  "@metamask-previews/user-operation-controller": "14.0.1-preview-1e84326"
}

@kanthesha
Copy link
Contributor Author

Record<never, never> is useful as the only way to represent an empty type object. The never index signature ensures that no property can be assigned to this type object.

  • The {} type is not an alternative, because it means NonNullable<unknown> instead of "empty object".
  • never is not an alternative, because any Record type is wider than the empty union.

That said, I agree that it's probably not being used correctly in this case.

Yeah, if there are params, it can be passed. If there're no params for the method, then no need to pass anything (params is optional)! We don't see a purpose of Record<never, never> type here!

@kanthesha kanthesha marked this pull request as draft August 21, 2024 15:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Fix Invalid type assignment in SafeEventEmitterProvider
2 participants