[Feature] Don't depend on node_modules because not everyone is using it

[rightaway]

Not everyone is installing their application using npm. There are bundlers that let you ship it as a binary and have no node_modules in the runtime. Playwright is looking in browsers.json in node_modules to find the path to the directory it needs and fails if it's not there.

This is convoluted and it will be better to give us the option to pass our own path like chromium.launch("~/.cache/my-own-chromium-directory"). We shouldn't have to worry about playwright managing versions or installations if we don't want it.

Give us the option to control what version we want to use and where that directory is. That will make it a lot easier to use playwright from any environment and without depending on npm or node_nodules.

[rightaway]

For people managing browsers themselves, it should be possible to download the browser builds from your CDN. Then when we upgrade the version of playwright we're using we can simply check the release notes to find the compatible version numbers and download those from the CDN to where the application is running in production.

To make that easier since browsers.json is an implementation detail https://github.com/microsoft/playwright/issues/7317#issuecomment-868861759, there could be a function like playwright.getBrowser("chromium", "~/.cache/my-own-chromium-directory") which would download whatever the version of chromium supported by the current version of playwright into the directory if necessary. We could call this whenever we start the application and would be sure the application is always up to date.

These changes aren't breaking and won't affect anyone who wants to let playwright manage everything for them, but will allow people who have more advanced use cases to use playwright with no problems.

[aslushnikov]

Give us the option to control what version we want to use and where that directory is.

@rightaway

• you can pick the directory with browsers easily using env variables. Take a look at our docs: https://playwright.dev/docs/browsers#managing-browser-binaries
• single playwright version is bound to a single set of browser versions; if you want to use different browser version, you should use different playwright version as well.

[rightaway]

Without a way to get the right files from your CDN, such as through a http link we can manage in provisioning scripts, anyone using a more advanced setup will get a "Executable doesn't exist" error when trying to run it since the browsers don't exist in production.

If each version's browser files (like chromium-1012 or firefox-1327) can have public links, when we upgrade playwright we can just check the release notes, use http to download the compatible browser files for that version to the cache directory, and everything will work.

With publicly available files for download, there doesn't need to be any change to playwright itself.

[aslushnikov]

Without a way to get the right files from your CDN, such as through a http link we can manage in provisioning scripts, anyone using a more advanced setup will get a "Executable doesn't exist" error when trying to run it since the browsers don't exist in production.

@rightaway You get these files by running npx playwright install. You can spawn this process from your script if you'd like! What exactly doesn't work today?

[rightaway]

It's for machines that don't have npm because the application was complied to binary before being deployed.

https://github.com/microsoft/playwright/blob/main/packages/playwright-core/src/server/registry/index.ts has links to download the files. Can the links be documented? We can download files like https://playwright.azureedge.net/builds/chromium/1012/chromium-linux.zip and don't need to install npm when an http request is enough.

[aslushnikov]

It's for machines that don't have npm because the application was complied to binary before being deployed.

I see. So this doesn't seem to be web-testing related.

Can the links be documented?

We'd rather not. We'll have to setup some infra to keep them always up-to-date, and this will add complexity on our plate. For those who're interested in direct links, these could be always inferred from the source base like you already did.

[aslushnikov]

My triaging shift is over, and I don't think we should do anything about it, so I'll close this for now. But please do not hesitate to file a new issue if things don't work for you!