AsyncIterable still raises compile issue with 3.6.1 if target is not set to ES2018

[ibdafna]

Seems to be caused by the following line:
https://github.com/jupyterlab/jupyterlab/blob/3.6.x/packages/services/src/event/index.ts#L183

➜ jlpm build
yarn run v1.21.1
$ jlpm build:lib && jlpm build:labextension:dev
$ tsc --sourceMap
node_modules/@jupyterlab/services/lib/event/index.d.ts:89:52 - error TS2583: Cannot find name 'AsyncIterable'. Do you need to change your target library? Try changing the `lib` compiler option to 'es2018' or later.

89     interface IStream<T, U> extends ISignal<T, U>, AsyncIterable<U> {
                                                      ~~~~~~~~~~~~~


Found 1 error.

error Command failed with exit code 1.

[krassowski]

Is this with 3.6.0 or 3.6.1? See previous discussion in #13913.

[ibdafna]

It's with 3.6.1

[fcollonval]

To fix this in extension, see the migration note in the documentation: https://jupyterlab.readthedocs.io/en/stable/extension/extension_migration.html#asynciterable-support

[ibdafna]

Thanks @fcollonval, I saw the migration guide but I'm still confused because it does say the target was reverted to ES2017 in JLab 3.6.1, which does not seem to be the case.

JupyterLab 3.6.0 was released with an updated target “ES2018”. We strongly advise updating to 3.6.1, which reverts the target back to “ES2017”.

[fcollonval]

The target is changing the produced JS assets but not the typing files. Therefore the .d.ts emitted still contain AsyncIterable types. If you don't want to change the target in your downstream extension, you need to inform typescript on the types it does not know. You can do this by adding ES2018 to the lib TS option - this is similar to adding/bumping @types/ package.

You could also use skipLibCheck - but this is a bad practice.

[krassowski]

We could try shipping our custom types patch in the future to avoid breaking the developer experience for extension developers. I used this approach when backporting content-visibility mode in lumino without switching target: jupyterlab/lumino#500 by patching up CSSStyleDeclaration interface. Would that work?

[fcollonval]

We could try shipping our custom types patch in the future to avoid breaking the developer experience for extension developers. I used this approach when backporting content-visibility mode in lumino without switching target: jupyterlab/lumino#500 by patching up CSSStyleDeclaration interface. Would that work?

That is a good question. Looking at the typescript type definition:

/// <reference lib="es2015.symbol" />
/// <reference lib="es2015.iterable" />

interface SymbolConstructor {
    /**
     * A method that returns the default async iterator for an object. Called by the semantics of
     * the for-await-of statement.
     */
    readonly asyncIterator: symbol;
}

interface AsyncIterator<T, TReturn = any, TNext = undefined> {
    // NOTE: 'next' is defined using a tuple to ensure we report the correct assignability errors in all places.
    next(...args: [] | [TNext]): Promise<IteratorResult<T, TReturn>>;
    return?(value?: TReturn | PromiseLike<TReturn>): Promise<IteratorResult<T, TReturn>>;
    throw?(e?: any): Promise<IteratorResult<T, TReturn>>;
}

interface AsyncIterable<T> {
    [Symbol.asyncIterator](): AsyncIterator<T>;
}

interface AsyncIterableIterator<T> extends AsyncIterator<T> {
    [Symbol.asyncIterator](): AsyncIterableIterator<T>;
}

it seems possible. But I have no idea if this will always be the case - I guess if some new fundamental type were to be defined it won't be possible.