Include installed `playwright-core` package in Dockerfile

[VaasRamsay]

🚀 Feature Request

Retain the /ms-playwright-agent dir in Dockerfile so the container is ready to run Playwright without extra steps.

Example

No response

Motivation

The Dockerfile installs playwright-core package in the /ms-playwright-agent dir but cleans up at the end. So users have to install as part of their CI setup. This becomes an little inconvenient for server-containers (where we just launch browser server & tests run elsewhere connect to this container). Users either have to build another image to do this or do the setup during container start (which is not efficient).

[mxschmitt]

As of today this is intentional, since different package managers install playwright in different locations. It's often not only about playwright-core, its also about @playwright/test. Most of the end-to-end testing projects we've seen depend on third-party libraries as well - so it wouldn't be beneficial for them. So "npm ci" is usually the way to go.

[VaasRamsay]

My project uses TestContainers to orchestrate all dependencies for tests. So every test will spin up the needed containers, which includes the Playwright container as well. It's a big overhead to run npm ci during container startup, as it's done for every single startup.

[mxschmitt]

I'm not familiar with Testcontainers. Usually installing Playwright takes 2-4 seconds via NPM, since the browsers/OS dependencies are already satisfied in the Docker container. Would you like to reduce this to 0?

Looks like they have no official support for Playwright yet? https://github.com/testcontainers/testcontainers-dotnet/issues/1033 so maybe they will address it there,

There is a PR which was closed: https://github.com/testcontainers/testcontainers-node/pull/726.

[eddumelendez]

Hi from Testcontainers team 👋🏽 , in the past we have been looking into adding integration with Playwright but we realized the source code had to be copied into the container in order to execute it. This is something we don't usually do. As the issue described, tests using Testcontainers executes in a different process and connects to the dependencies provided via containers. This also plays right with remote docker environments. Looking at this issue, it is was we are missing in order to provide a better integration. Let's also take into account Testcontainers provides random port instead of fixed ports.

Although, installing is another option. It will depend on an environment connected to internet. If a image is provided then users can play in offline as well once the image is cached.

Looking forward to see comments and provide better integration.