[6.0.0+] New Typings break existing Typescript Code

Steps to reproduce

Tell us about your environment:

• Puppeteer version: >6.0.0
• Platform / OS version: any
• URLs (if applicable):
• Node.js version: any

What steps will reproduce the problem?

Please include code that reproduces the issue.

1. Use e.g. the LaunchOptions type
2. Upgrade to >6.0.0
3. Enjoy type Errors

What is the expected result?

Instead of just redefining, merging, or renaming types, original types should be kept and possibly extended or split. At the very least I would expect some clear documentation what types changed.

What happens instead?

Types have been renamed, moved, merged or broken without any clear indication in the changelogs. As an example:

LaunchOptions has been reduced to a subset of it’s original interface and is now extended with

LaunchOptions & BrowserLaunchArgumentOptions  & BrowserConnectOptions & {
    product?: Product;
    extraPrefsFirefox?: Record<string, unknown>;
}

There is also a PuppeteerNodeLaunchOptions which is used for the ProductLauncher interface and is pretty close to the original LaunchOptions (LaunchOptions & BrowserLaunchArgumentOptions & BrowserConnectOptions).

What I don’t understand is why LaunchOptions hasn’t been kept and instead been split into the before mentioned parts. This is quite a breaking change nor does it make the typings any cleaner or easier to use.

This is justn an example, see below comment for complet(ish)l list

---

I’m sure there might be a duplicate of this issue, but with a quick search I could only find some issues on broken typings. These renamed types are critical for projects like puppeteer-extra https://github.com/berstend/puppeteer-extra/issues/428. If there is a duplicate, I’m sorry, but I don’t have the time to screen 1500 open issues atm.

Anyway, I’d love to keep using the new versions of puppeteer, but right now the typings are a pretty big obstacle.

[ptommasi]

I’m having the same issue, at the moment the workaround I found is to use:

const puppeteer = require('puppeteer-extra');
puppeteer.use(require("puppeteer-extra-plugin-stealth")());
puppeteer.use(require("puppeteer-extra-plugin-block-resources")({ "blockedTypes": new Set(["stylesheet", "font", "texttrack", "other", "image", "xhr", "media" ]) }));

Instead of importing it (basically I’m losing the typing in order to make TypeScript happy).

If I import puppeteer (or { PuppeteerExtra }) from “puppeteer-extra”, this is the message I get:

> tsc && node --trace-warnings dist/app.js 

node_modules/puppeteer-extra/dist/puppeteer.d.ts:4:10 - error TS2305: Module '"puppeteer"' has no exported member 'ChromeArgOptions'.

4 export { ChromeArgOptions } from 'puppeteer';
           ~~~~~~~~~~~~~~~~

node_modules/puppeteer-extra/dist/puppeteer.d.ts:6:10 - error TS2305: Module '"puppeteer"' has no exported member 'FetcherOptions'.

6 export { FetcherOptions } from 'puppeteer';
           ~~~~~~~~~~~~~~

I’d like to use two instances of puppeteer extra (one with filters, one without), any idea?

[jackfranklin]

Hi all,

Sorry for the slow action here and silence. All this feedback is really useful; we were aware that in shipping our own types we would definitely find places where we miss things that the @types/puppeteer package exposed and it’s our goal to fix them. Some renames happened because old Puppeteer names clashed with TypeScript built ins (Request is a good example) and others happened because we felt it could make them clearer. We’re doing this work alongside a big drive to improve the documentation (more on that to come in the future hopefully) so some renames have been to try to make it easier to document.

Going forwards from our current version (v8), I would expect us to treat TS breaking changes just as we would treat API changes as breaking, so I hope that we can be more stable moving forwards, and I totally understand the way we rolled out the TS changes was, in hindsight, not ideal for helping people upgrade and adopt Puppeteer and also not ideal for those who maintain libraries built to work with Puppeteer. I’m sorry that this wasn’t the smooth rollout we would have ideally had.

This week I’ll go through the types documented in this issue and look into them to clarify if we can land PRs for the next release that fix some of them, or if I can help with renames. In the long term us shipping our own types should mean increased TS coverage going forward but it will take some time and effort to get there.