generate .d.ts better than what's on definitelytyped

[JoelEinbinder]

• Types include descriptions from api.md
• Private methods are excluded
• Private intermediate types are excluded
• Typed protocol for ChromiumSession
• Don't lose type information from page.evaluate
• Templated JSHandles
• Always up to date with the API
• Consider types part of the API, never break them
• Enums for important string constants, e.g. LifecycleEvent and KeyboardKey.
• Sort out waitFor's many call signatures

[dgozman]

I suggest to drop ChromiumSession from v1 altogether.

[mxschmitt]

Is it also possible, that a single file will be created which contains all the typings in the end? Like Electron does. Or is this already included / done in your task list / PR?

cc @JoelEinbinder

Thanks!

[JoelEinbinder]

Is it also possible, that a single file will be created which contains all the typings in the end? Like Electron does. Or is this already included / done in your task list / PR?

cc @JoelEinbinder

Thanks!

I didn’t have that as an explicit goal, but it will likely end up with one file for the core types, and one file per package like playwright, playwright-chromium, that reexports some of those types. Is there some reason that having a single file with all of the types is preferable?

[mxschmitt]

Is it also possible, that a single file will be created which contains all the typings in the end? Like Electron does. Or is this already included / done in your task list / PR?
cc @JoelEinbinder
Thanks!

I didn’t have that as an explicit goal, but it will likely end up with one file for the core types, and one file per package like playwright, playwright-chromium, that reexports some of those types. Is there some reason that having a single file with all of the types is preferable?

I try to embed the typings into the Monaco editor to use them there and for that I need to load them "somehow" into the frontend. For Electron (just a random example) it works by simply using the single file, thats why I thought this is common.

[thernstig]

This snippet does not give proper types for el:

    await page.$eval('input[type=text]', el => {
      // @ts-ignore
      el.value = '';
    });

I'm using VS Code. Removing // @ts-ignore will give an error saying Property 'value' does not exist on type 'Element'.ts(2339). Is this part of this issue?

[JoelEinbinder]

This snippet does not give proper types for el:

    await page.$eval('input[type=text]', el => {
      // @ts-ignore
      el.value = '';
    });

I'm using VS Code. Removing // @ts-ignore will give an error saying Property 'value' does not exist on type 'Element'.ts(2339). Is this part of this issue?

No this is standard behavior with typescript. Replace $eval with document.querySelector and the same thing will happen.

[thernstig]

@JoelEinbinder or @aslushnikov Any recommended way to work around that, i.e. to achieve the same thing but with autocompletion for el? Basicallly what I want to do is reset an input field at the start of each test I run. Is the the only workaround to get auto-completion to do like below? Below el does give auto-completion, hence why I thought page.$eval would also give it after finding the element.

const foo= await page.waitForSelector('text="Something"');
expect(await foo.evaluate(el => el.innerText)).toBe('Something');

[JoelEinbinder]

@JoelEinbinder or @aslushnikov Any recommended way to work around that, i.e. to achieve the same thing but with autocompletion for el? Basicallly what I want to do is reset an input field at the start of each test I run. Is the the only workaround to get auto-completion to do like below? Below el does give auto-completion, hence why I thought page.$eval would also give it after finding the element.

const foo= await page.waitForSelector('text="Something"');
expect(await foo.evaluate(el => el.innerText)).toBe('Something');

I believe waitForSelector had the wrong types. They should both behave the same after my pr lands.

[thernstig]

@JoelEinbinder I will follow this up once your PR lands and report any existing issues I have, so we can sort it out what's incorrect and not. I find it so weird that this (see image) gives autocompletion for everything but .value.

[thernstig]

@JoelEinbinder Did you see my above image? There you can see that el.nodeValue gives auto-completion, but not el.value. Do you mean that el.value will never give auto-completion then? If so, how do I work around this in e.g. VS Code?

    await page.$eval('input[type=text]', el => {
      // @ts-ignore
      el.value = '';
    });

[dgozman]

If I am not mistaken, manual typing should work in this case:

await page.$eval('input[type=text]', (el: HTMLInputElement) => {
  el.value = '';
});

[mxschmitt]

HTMLInputElement

then something like that comes up, I also faced into this issue:

No overload matches this call.
  Overload 1 of 4, '(selector: string, pageFunction: PageFunctionOn<HTMLElement | HTMLInputElement | HTMLObjectElement | HTMLAnchorElement | HTMLAppletElement | ... 66 more ... | HTMLVideoElement, void, string>, arg?: any): Promise<...>', gave the following error.
    Argument of type '(el: HTMLInputElement) => string' is not assignable to parameter of type 'PageFunctionOn<HTMLElement | HTMLInputElement | HTMLObjectElement | HTMLAnchorElement | HTMLAppletElement | ... 66 more ... | HTMLVideoElement, void, string>'.
      Type '(el: HTMLInputElement) => string' is not assignable to type '(on: HTMLElement | HTMLInputElement | HTMLObjectElement | HTMLAnchorElement | HTMLAppletElement | ... 66 more ... | HTMLVideoElement, arg2: void) => string | Promise<...>'.
        Types of parameters 'el' and 'on' are incompatible.
          Type 'HTMLElement | HTMLInputElement | HTMLObjectElement | HTMLAnchorElement | HTMLAppletElement | ... 66 more ... | HTMLVideoElement' is not assignable to type 'HTMLInputElement'.
            Type 'HTMLElement' is missing the following properties from type 'HTMLInputElement': accept, align, alt, autocomplete, and 49 more.
  Overload 2 of 4, '(selector: string, pageFunction: PageFunctionOn<HTMLOrSVGElement, void, string>, arg?: any): Promise<string>', gave the following error.
    Argument of type '(el: HTMLInputElement) => string' is not assignable to parameter of type 'PageFunctionOn<HTMLOrSVGElement, void, string>'.
      Type '(el: HTMLInputElement) => string' is not assignable to type '(on: HTMLOrSVGElement, arg2: void) => string | Promise<string>'.
        Types of parameters 'el' and 'on' are incompatible.
          Type 'HTMLOrSVGElement' is not assignable to type 'HTMLInputElement'.
            Type 'SVGElement' is missing the following properties from type 'HTMLInputElement': accept, align, alt, autocomplete, and 69 more.

Something like that works:

page.$eval(selector, (el) => (el as HTMLInputElement).value)

[thernstig]

If I am not mistaken, manual typing should work in this case:

await page.$eval('input[type=text]', (el: HTMLInputElement) => {
  el.value = '';
});

We are not using TypeScript. The reason we see the failures is because VS Code has type inference via their language service, so the above approach will not work for us.

[dgozman]

@mxschmitt After #1747 (should be available in the upcoming playwright@next release), explicit (el: HTMLInputElement) => el.value should work.

@thernstig I am not sure what to do about VSCode being smart with javascript, but not allowing type annotations. Perhaps, JSDoc-style comments could help? Any ideas are welcome!

[thernstig]

Yes maybe there is just so much VS Code can infer. We have a large code base and I haven't seen this problem with other code, but unfortunately I have got little knowledge of TypeScript so I also cannot be of much help as to why/how to solve this best. I hope to invest time in TypeScript soon enough to be able to be of better help with feedback such as this.

[pavelfeldman]

This bug is now too big to track, let's close it as fixed and open new fine-grained bugs for the missing features!