Typescript 5.6

[turadg]

evergreen

Description

https://devblogs.microsoft.com/typescript/announcing-typescript-5-6

Notable changes for this repo,

• Strict Builtin Iterator Checks (and --strictBuiltinIteratorReturn)

Security Considerations

n/a

Scaling Considerations

n/a

Documentation Considerations

none

Testing Considerations

I captured type coverage before and after.

Upgrade Considerations

n/a

[cloudflare-workers-and-pages]

Deploying agoric-sdk with    Cloudflare Pages

Latest commit:	37e43c6
Status:	✅  Deploy successful!
Preview URL:	https://9063a5b3.agoric-sdk.pages.dev
Branch Preview URL:	https://typescript-5-6.agoric-sdk.pages.dev

View logs

[mhofman]

My understanding is that 5.6 went final last night, so let's switch to that instead of the rc. It also seems that they may have reverted some changes that caused some of the Node and Iterator types compatibility issues that had to be worked around here, so let's possibly consider stashing those for now.

[mhofman]

According to the proposal, on async iterators this is the equivalent of calling return().

Suggested change

	[Symbol.asyncDispose]() {
	throw Error('asyncDispose not implemented.');
	},
	async [Symbol.asyncDispose]() {
	await reader.return();
	},

[mhofman]

@turadg force-pushed the typescript-5.6 branch from e119569 to 7da7902 1 hour ago

As a matter of process, it's really difficult to review what changed from my previous review when the base commit this PR is staged on changed since the comparison of changes since last review is now broken. In general while the review is in progress, prefer merging changes from master if you must update the PR so that changes remain additive.

It also seems that they may have reverted some changes that caused some of the Node and Iterator types compatibility issues that had to be worked around here

Have we tried reverting the version bump of @types/node ? I am somewhat concerned about adding typing information for an API level we do not support.

[turadg]

As a matter of process…

I'll leave process discussions to internal forums.

Have we tried reverting the version bump of @types/node ? I am somewhat concerned about adding typing information for an API level we do not support.

Reverting the commit cause dozens of errors, all with the Buffer type due to IterableIterator types:

packages/internal/src/netstring.js:17:25 - error TS2322: Type 'Buffer' is not assignable to type 'Uint8Array'.
  The types returned by 'entries()' are incompatible between these types.
    Type 'IterableIterator<[number, number]>' is missing the following properties from type 'ArrayIterator<[number, number]>': map, filter, take, drop, and 9 more.

17   return Buffer.concat([prefix, data, suffix]);
                           ~~~~~~

We run CI tests with Node 18 so the only risk of Node 22 types is incorrect static analysis.

[mhofman]

due to IterableIterator types

Ah got it, it's due to Iterator helpers addition, not the other iterable object type change.

The problem is most likely because we target esnext in our tsconfig, instead of being more conservative.

We run CI tests with Node 18 so the only risk of Node 22 types is incorrect static analysis.

Of course, my goal was to keep the tools working as best as possible, and the development iteration short.

[turadg]

Bypassed integration because this PR has passed integration several times save for multichain-testing, and I just reverted the changes to that.