use puppeteer-core replace pupp

[superwf]

🚀 Feature Proposal

Add option to use puppeteer-core for replacement of puppeteer.

Motivation

In most cases users already have chrome installed in there system, and download puppeteer will also download a large Chromium bin file, each time the downloading cost some time.
Use puppeteer-core is lighter choice.

Example

https://github.com/superwf/jest-with-puppeteer-core

This exmple use module-alias to make puppeteer-core as an alias to puppeteer.

[gregberge]

Hello @superwf, I think it is a good idea to let the choice to the user. I have to check if it is possible to modify the code in order to accept both.

[gidztech]

This is a really good idea, and will speed up tests on CI environments that obtain the browser by other methods (Docker container in our case).

I think it's important to mention in the documentation for this config option, that Puppeteer is not guatanteed to work with any particular version of Chrome or Chromium other than the one shipped with it. They should use this option at own risk. See https://github.com/GoogleChrome/puppeteer/#q-why-doesnt-puppeteer-vxxx-work-with-chromium-vyyy

[gregberge]

Yes you are right, we have to mention it.

[WilliamDASILVA]

Hello,

Any news on this one?
Couldn't we pass the puppeteer instance in the config, and remove the puppeteer dependency ?

A suggestion would be to have something like:

const puppeteer = require('puppeteer')
module.exports = {
	puppeteerInstance: puppeteer
}

const puppeteer = require('puppeteer-core')
module.exports = {
	puppeteerInstance: puppeteer
}

Then in the jest-puppeteer code, we could use it:

config.puppeteerInstance.connect({
	// ...
})

[gregberge]

@WilliamDASILVA not for now, it is complicated to have this kind of behaviour with npm package system.

[isaachinman]

@neoziro So, no plans to support this?

[gregberge]

In fact, we should support it. It is the same issue as #171 for me. We have to remove peer dependencies and investigate which module is available during runtime. So to answer, yes we plan to support it.

[icfantv]

One issue I see with switching to puppeteer-core is that the with this package, the environment variables PUPPETEER_* will no longer work. Projects can have a local .npmrc file (i.e., at the project's root directory) to set a node config property to prevent the binaries from downloading via puppeteer_skip_chromium_download=true.

I just completed a spike whereby I have chrome running in a container and have my local puppeteer (i.e., the puppeteer in my project) connecting to it and executing tests. The main, required dependency will be getting the websocket URL from chrome in the running container PRIOR to the Jest tests executing (not difficult, but needs to be done) so you can do something like:

const webSocket = 'ws://localhost:9222/devtools/browser/eaec4f8e-0d72-4495-9369-8cbe5ac4ef08';
const browser = await puppeteer.connect({ browserWSEndpoint: webSocket });

But, clearly, without the hardcoded URL. But if I'm being honest, after doing this spike, I'm not really seeing any huge advantage jest-puppeteer could provide in this scenario. Do please feel free to chime in if you disagree or see advantages that I've missed.

[gidztech]

@icfantv The method you describe is what I use with jest-puppeteer-docker. It fetches a container from Docker hub which has the Chromium version linked to your local Puppeteer version dependency, and then I connect using the WebSocket. In order to prevent downloading Chromium when installing the Puppeteer dependency in CI, it just requires user to set PUPPETEER_SKIP_CHROMIUM_DOWNLOAD to true.

It looks like there's an open PR for supporting FireFox by dynamically importing the module based on config. If my understanding is correct, none of the Puppeteer dependencies are needed in jest-puppeteer project (just dev dependencies for internal tests). As long as they are installed as dependencies in the end-user's project, the module will be found further up the npm hierarchy. So on top of that PR, we can add an extra mode for core, maybe the option is simply browser: none. It would then rely on the end-user to use the connect option.

The above also means the environmental variables should work fine for those who use the browser: chromium (default) option.

[icfantv]

@gidztech yep, I saw/tried your solution last week and it was a bit too heavy for our use case. Since our Jenkins drones are not exposed to the Internet, we just need a way to host binaries and having Puppeteer connecting to chrome running in a container whose image we can store in Artifactory is a perfect solution for us. For proper credit, I got that solution working from this project.

[gziolo]

You can also use npm alias to workaround it as we did it for WordPress reusable scripts:
WordPress/gutenberg#20215

However, the ideal approach would be to make it work with puppeteer-core as well. Actually, I think the required change was already added with #315.