protocol-dts-generator for devtools-protocol typescript types

[nojvek]

Fixes #55 (typescript definitions)

TODO List

• Create a protocol-dts-generator in scripts.
• Generator invoked on publish via "prepublishOnly" command
• types entry in package.json
• Generated typescript definition: https://github.com/nojvek/devtools-protocol/blob/9edcecb0dcca0c2e654db94a3ba1fbf3eb94fd7e/types/protocol.d.ts
• Cleanup generator code
• Ensure protocol.json files are typechecked with protocol-schema.d.ts
• Some documentation on how to use .d.ts

[nojvek]

@paulirish ^

[JoelEinbinder]

This is very cool. I tried to use it to add types to puppeteer and ran into trouble with events. Having a separate method per event makes it difficult to work with. Id expect the domains to extend Node's EventEmitter and have events defined like

on(event: 'TargetInfoChanged', listener: (params: Target.TargetInfoChangedEvent) => void): this;

Also every method is marked as optional on every domain. Maybe this should correspond to whether or not the method is experimental? Or have some other indication of experimental vs stable methods.

[nojvek]

@JoelEinbinder done.

Yeah I left it as onXYZ because typescript would give better code completion, but they've fixed that since then.

Happy to take feedback on what you'd like the ideal interface to be.

do you simply want the interface to be .

send(command: 'Domain.xyz', params: SomeRequest): Promise<SomeResponse>
on(event: 'Domain.xyz', listener: (params: SomeEvent) => void): void

[paulirish]

protocol-schema, now, eh?

[brendankenny]

FWIW I've found the overloaded on() doesn't play well with using these types from js (using jsdocs), but OTOH it is the best way to get type inferencing from the compiler (to avoid given manual types to event responses). I'm playing with a different approach for Lighthouse since we have places that deal with consuming and producing (or at least re-playing) protocol methods. If I get it working I can make a proposal to combine it with this work so both options are supported.

All the info we need is in here, though, and as long as all the method definitions are on DomainApi or whatever (like you have now), we're good.

[nojvek]

@JoelEinbinder @brendankenny Please let me know your preferences for the final interface and I'll make the changes.

[brendankenny]

the protocol format you have now LGTM

[paulirish]

@JoelEinbinder you happy with the look of this now?

[paulirish]

@nojvek the remaining TODOs are some good stuff. do you want to do those in this PR or the next one? Ideally we wouldn't delay it too much.

[nojvek]

I’m happy it being a v1 and work on documentaion and protocol steps in next PR

How does the publish of npm modules work? I imagine some bot runs the script?

[paulirish]

@nojvek Yup. Done by a bot every hour.

[themaxdavitt]

I created a PR to ensure the *_protocol.json files are typechecked with protocol-schema.d.ts (from the TODO list): #211