Be careful to avoid breaking changes in with the typescript types.

[JoelEinbinder]

Right now, its easy to introduce breaking changes with our typescript types without realizing it.

• Object literal types get names like ClassMethodArgument. If the argument name changes, the type name changes, and that is a breaking change.
• If we have dog.speak(options) we will have a DogSpeakOptions type. If in a later version, we move speak to the animal class which dogs inherits from, we will only have AnimalSpeakOptions and DogSpeakOptions will be removed. This will be a breaking change.

There are probably some other subtle ways to introduce breaking changes that I have no thought of.

Possible mitigations

• Add a test that checks that current types are a strict superset of the previously released types, unless this revision is a breaking change.
• Manually add old types back into the api to make sure there are no breaking changes.
• Don't export all parameter type objects, instead manually construct a set of useful types to export, and keep that from having breaking changes.

[dgozman]

• Don't export all parameter type objects, instead manually construct a set of useful types to export, and keep that from having breaking changes.

I want to try this approach. This way we can be sure our types are good. For example, we currently have PageFilechooserPayload which should actually be an object with methods (to account for feature creep), but currently it ha a bunch of optional properties.

[JoelEinbinder]

This is mostly done, except that we should add a test that lints our current types against the old ones.

[JoelEinbinder]

I tried to add a test that lints our current types against the old ones. It was stymied in two ways.

• doc: fix the route docs #2174 appears to have broken the types, but it actually fixed the types where they didn't match the implementation
• our CDPSession types break pretty much every release, but we don't make any guarantees here.

Closing this as infeasible.