Skip to content

Support async_sequence - #2533

Merged
github-actions[bot] merged 11 commits into
microsoft:mainfrom
Bashamega:feat/update-bcd
Aug 30, 2026
Merged

Support async_sequence#2533
github-actions[bot] merged 11 commits into
microsoft:mainfrom
Bashamega:feat/update-bcd

Conversation

@Bashamega

Copy link
Copy Markdown
Contributor

closes #2480

@saschanaz

Copy link
Copy Markdown
Contributor

Please just do the async_sequence part, the other parts are too big to consume.

@Bashamega

Copy link
Copy Markdown
Contributor Author

Please just do the async_sequence part, the other parts are too big to consume.

Sure, but how can we test it without upgrading the library?

@saschanaz

Copy link
Copy Markdown
Contributor

That's a good question. But it's kinda more important to make the job pass than making it correct right now, we'll get it checked later when we get the actual IDL updated.

-
Signed-off-by: Bashamega <adambashaahmednaji@gmail.com>
Signed-off-by: Bashamega <adambashaahmednaji@gmail.com>
@Bashamega

Copy link
Copy Markdown
Contributor Author

That's a good question. But it's kinda more important to make the job pass than making it correct right now, we'll get it checked later when we get the actual IDL updated.

Done. Thanks for looking at this. When will you check my previous PRs? Or should I close them?

@Bashamega Adam Naji (Bashamega) changed the title Update Bcd & support async_sequence Support async_sequence Aug 28, 2026
Comment thread src/build/emitter.ts Outdated
}
return "AsyncIterable";
} else {
// Legacy main & fallback builds: no async iterable interface available.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

What is main & fallback builds? Can we say legacy TS versions?

Comment thread src/build/emitter.ts Outdated
if (compilerBehavior.treatAsyncSequence) {
// Forwards-compatible definition:
// NOTE: In IDL→TS (whatwg/streams#1372 etc) async_sequence<T> -> AsyncIterable<T>
// If stricter interop wanted, could use AsyncIterable<T> | Iterable<T>

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Why?

Comment thread src/build/emitter.ts Outdated
// For TS <2.3, the generator separates out [Symbol.asyncIterator] into *.asynciterable.d.ts, so
// these references must not leak into the main file, so we can treat them as `any` as a fallback.
if (compilerBehavior.treatAsyncSequence) {
// Forwards-compatible definition:

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

forwards-compatible?

Comment thread src/build/emitter.ts Outdated
// Support async_sequence (see https://github.com/whatwg/streams/pull/1372)
if (obj.type === "async_sequence") {
// If we're in a build that includes async iterables (TS 2.3+ or forced), emit as AsyncIterable<T>.
// For TS <2.3, the generator separates out [Symbol.asyncIterator] into *.asynciterable.d.ts, so

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I don't think we care about TS < 2.3, minimum supported version is already 4.4.

That said, AsyncIterable does require separate asynciterable.d.ts until TS 6.0, so to make it correct we need to defer any functions that uses async_sequence to asynciterable variant.

Given we don't really test it here, it's also acceptable to just entirely skip the generation for those functions with some console warning.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I don't think we are doing this?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I don't quite understand this comment but i have pushed a change tell me if this is what you mean

Comment thread src/build.ts Outdated
outputFolder: new URL("./ts5.5/", outputFolder),
compilerBehavior: {}, // ts5.5 does not support `IteratorObject` or unrelated setter types
compilerBehavior: {
treatAsyncSequence: false,

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Let it just empty as others did here

@Bashamega

Copy link
Copy Markdown
Contributor Author

done

Comment thread src/build.ts Outdated
compilerBehavior: {
useIteratorObject: true,
allowUnrelatedSetterType: true,
treatAsyncSequence: false,

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Again, please skip it as others do

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Sorry, done

Comment thread src/build/emitter.ts Outdated
const type = convertBaseType();
if (type === "any") {
return type;
}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Does this still matter?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Updated

@saschanaz

Copy link
Copy Markdown
Contributor

Thanks!

For future reference - I think the fix is in a wrong place - Ideally it should be somewhere in emitMethod or the caller of emitMethod, check the return type from there, and skip the emission for older TS versions. We should not emit any because that's unrecoverable with overloads.

But for now this is okay as we'll check it later.

LGTM

@github-actions
github-actions Bot merged commit 23be9eb into microsoft:main Aug 30, 2026
5 checks passed
@github-actions

Copy link
Copy Markdown
Contributor

Merging because Kagami Sascha Rosylight (@saschanaz) is a code-owner of all the changes - thanks!

@saschanaz
Kagami Sascha Rosylight (saschanaz) deleted the feat/update-bcd branch August 30, 2026 15:15
@saschanaz

Copy link
Copy Markdown
Contributor

As for future work - I think it would be nice to consume each of webref/idl and BCD updates release-by-release to reduce #2495 and eventually close it.

About KDL work - I have been thinking of having a library - https://codeberg.org/krosylight/kdl2json, but hasn't been made any progress recently. I was thinking maybe I should encourage contribution once I get it more in form, but any help (or any question for future direction to contribute for) would be nice.

@Bashamega

Copy link
Copy Markdown
Contributor Author

As for future work - I think it would be nice to consume each of webref/idl and BCD updates release-by-release to reduce #2495 and eventually close it.

About KDL work - I have been thinking of having a library - https://codeberg.org/krosylight/kdl2json, but hasn't been made any progress recently. I was thinking maybe I should encourage contribution once I get it more in form, but any help (or any question for future direction to contribute for) would be nice.

Hello,
Thank you for sharing this with me.
I would love to help you out.
Please tell me how I can help out with the kdl2json library. Meanwhile I will try to reduce the pr.

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.

Support new WebIDL async_sequence<T> type

4 participants