fix: optional type narrow: getEvents, getTransactionTrace, estimateMe…

[tabaktoni]

Motivation and Resolution

Uncertainty on params and response type for union Provider methods
Instead of an explicit response, casting a user can now do an explicit expected type

-optional type narrow: getEvents, getTransactionTrace, estimateMessageFee, getL1MessagesStatus

Usage related changes

const result: RPCSPEC010.EVENTS_CHUNK = await provider.getEvents<typeof constants.SupportedRpcVersion.v0_10_0>(filter);
//or
const result: RPCSPEC010.EVENTS_CHUNK = await provider.getEvents<'0.10.0'>(filter);

I'm not convinced this is better than current type casting, but I'll let commenters decide.
One obvious advantage is that param is hard typed, so there is no option to pass false params.

Checklist:

• Performed a self-review of the code
• Rebased to the last commit of the target branch (or merged it into my branch)
• Linked the issues which this PR resolves
• Documented the changes in code (API docs will be generated automatically)
• Updated the tests
• All tests are passing

[PhilippeR26]

In all cases, it's necessary to add 2 types:

const filter = {...}
const eventsRes: RPC.RPCSPEC010.EVENTS_CHUNK = await myProvider.getEvents<"0.10.0">(filter);

or

const filter: RPC.RPCSPEC010.EventFilter = {...}
const eventsRes = await myProvider.getEvents<"0.10.0">(filter);

Without this PR, it's easier with only one type declaration:

const filter = {...}
const eventsRes  = (await myProvider.getEvents(filter)) as RPC.RPCSPEC010.EVENTS_CHUNK;

So, we have to choose

• one type declaration, but with a AS
• 2 type declarations, but without any AS

Personally, I prefer a short and quick solution (so with a AS), but I understand that TYPE SCRIPT fundamentalists can prefer the other one.

[tabaktoni]

In all cases, it's necessary to add 2 types:

const filter = {...}
const eventsRes: RPC.RPCSPEC010.EVENTS_CHUNK = await myProvider.getEvents<"0.10.0">(filter);

or

const filter: RPC.RPCSPEC010.EventFilter = {...}
const eventsRes = await myProvider.getEvents<"0.10.0">(filter);

Without this PR, it's easier with only one type declaration:

const filter = {...}
const eventsRes  = (await myProvider.getEvents(filter)) as RPC.RPCSPEC010.EVENTS_CHUNK;

So, we have to choose

• one type declaration, but with a AS
• 2 type declarations, but without any AS

Personally, I prefer a short and quick solution (so with a AS), but I understand that TYPE SCRIPT fundamentalists can prefer the other one.

This PR does not change the old way; you can still do as before.
But it improves on the input parameter type.
so

const a = method<"0.10.0">(param)

old way still available

const a = method(param as RPC010typeX) as RPC010typeY;

In both cases, const a will be inherited from the response type, so no advantage in factual type definition.
The actual advantage is that you can forget to cast the input parameter, and you need to know the exact types.
In the new way, you just say "hey, TS uses here RPC 0.10 definitions for this method and not RPC 0.9," and don't care about what dose types are, and let TS do validity checks for you.

[github-actions]

🎉 This PR is included in version 9.2.2 🎉

The release is available on:

• npm package (@next dist-tag)
• GitHub release

Your semantic-release bot 📦🚀