Large bundle size with webpack

Actual Behavior

I’m making a Chrome recorder extension, and I’ve noticed the production library bundle was 437KB in my project, which I would consider to be relatively large for a bundle that doesn’t need to ship GUI assets. I’m guessing this is due to a combination of Node.js dependencies and Puppeteer not being originally designed for browser usage (since the DOM and Selenium APIs already support browser automation). This issue may also apply to Puppeteer’s build, but I wanted to open it here because it’s related to the recorder use case.

Steps to Reproduce the Problem

1. Clone https://gist.github.com/ad7d2641f9b7b8c6012d031edab790c4
2. npm install
3. Note the sizes outputted by webpack or on disk

Specifications

• Version: 0.6.1
• Platform: macOS

[OrKoN]

Hey @nickmccurdy I suspect that you don’t require Puppeteer for the extension as we currently only support export extensions? In that case, you can safely exclude Puppeteer (which is an optional peer dependency needed for the replay part) from the bundle. Please see this rollup config https://github.com/cypress-io/cypress-chrome-recorder-extension/blob/main/rollup.config.js#L10 as an example in rollup. I believe a similar configuration should be possible for Webpack. Would that work for your extension?

[nickmccurdy]

Sorry, got distracted working on other things for the extension.

Adding "sideEffects": false to node_modules/@puppeteer/replay/package.json seems to work, as it results in the main.js bundle being empty. This is closer to what we want, because we told webpack it has no side effects and we aren’t using any imports from it. However, this unfortunately still requires installing puppeteer and getting webpack to build it with the fairly large resolve.fallback config.

Does anyone have ideas on how to tree shake away Puppeteer without having to install or configure it?