update puppeteer to use the its generated cdp protocol types

[connorjclark]

Please fill in this template.

• Use a meaningful title for the pull request. Include the name of the package modified.
• Test the change in your own code. (Compile and run.)
• Add or edit tests to reflect the change. (Run with npm test.)
• Follow the advice from the readme.
• Avoid common mistakes.
• Run npm run lint package-name (or tsc if no tslint.json is present).

Select one of these and delete the others:

If changing an existing definition:

• Provide a URL to documentation or source code which provides context for the suggested changes: fix(types): publish protocol types to npm puppeteer/puppeteer#5174
• If this PR brings the type definitions up to date with a new version of the JS library, update the version number in the header.
• If you are making substantial changes, consider adding a tslint.json containing { "extends": "dtslint/dt.json" }. If for reason the any rule need to be disabled, disable it for that line using // tslint:disable-next-line [ruleName] and not for whole package so that the need for disabling can be reviewed.

[connorjclark]

The goal here is to not force users to update puppeteer - these types are for power users, so shouldn't force everyone to update. If these are missing, the CDPSession types use a sensible fallback of method: string | number | symbol and params: any, which isn't much different from the previous.

Unfortunately there doesn't seem to be a way to disable this rule. I tried:

// tslint:disable-next-line ban-ts-ignore
// tslint:disable-next-line ts-ignore

[SimonSchick]

I'd kindly ask you to way until my puppeteer 2.0 PR lands #40284

I'm currently working on it.

OT: This feels pretty hacky, if you really want to support TS as first class, why not move the project to TS all together?

[connorjclark]

Porting puppeteer to TS would be a huge effort.

Yeah it's pretty hacky - I think the "don't force to update for no benefit" constraint can be avoided if we 1) wait for next puppeteer version to be released (@mathiasbynens, maybe we could do a patch release?), which will have this protocol file published and 2) tack this change onto your PR, setting the minimum version to the next (unreleased 2.0.1) version

[SimonSchick]

@connorjclark iirc the // Type definitions for PACKAGE MAJOR.MINOR line does not support specifying patch versions (which makes sense since the public API shouldn't change).
I think it would be reasonable to do a minor release in this case.

[connorjclark]

This doesn't need to land until puppeteer/puppeteer#5174 is published - I'll comment on this PR when it's ready.

[typescript-bot]

@connorjclark Thank you for submitting this PR!

🔔 @marvinhagemeister @cdeutsch @ksm2 @SimonSchick @serbanghita @JasonKaz @davecardwell @angrykoala - please review this PR in the next few days. Be sure to explicitly select Approve or Request Changes in the GitHub UI so I know what's going on.

If no reviewer appears after a week, a DefinitelyTyped maintainer will review the PR instead.

[typescript-bot]

@connorjclark The Travis CI build failed! Please review the logs for more information.

Once you've pushed the fixes, the build will automatically re-run. Thanks!

[typescript-bot]

👋 Hi there! I’ve run some quick measurements against master and your PR. These metrics should help the humans reviewing this PR gauge whether it might negatively affect compile times or editor responsiveness for users who install these typings.

Let’s review the numbers, shall we?

Comparison details 📊

	master	#40432	diff
Batch compilation
Memory usage (MiB)	113.7	114.7	+0.9%
Type count	19212	19232	0%
Assignability cache size	38168	38172	0%
Language service
Samples taken	1175	1175	0%
Identifiers in tests	1175	1175	0%
getCompletionsAtPosition
Mean duration (ms)	601.4	594.3	-1.2%
Mean CV	9.3%	9.0%
Worst duration (ms)	751.0	730.6	-2.7%
Worst identifier	s	evaluateHandle
getQuickInfoAtPosition
Mean duration (ms)	597.8	588.6	-1.5%
Mean CV	9.5%	9.0%	-5.5%
Worst duration (ms)	713.2	729.6	+2.3%
Worst identifier	launch	Documents

It looks like nothing changed too much. I won’t post performance data again unless it gets worse.

[typescript-bot]

@connorjclark I haven't seen anything from you in a while and this PR currently has problems that prevent it from being merged. The PR will be closed tomorrow if there aren't new commits to fix the issues.

[typescript-bot]

@connorjclark To keep things tidy, we have to close PRs that aren't mergeable but don't have activity from their author. No worries, though - please open a new PR if you'd like to continue with this change. Thank you!