Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

playwright tests have stopped working in deno v2.1.5 #27623

Open
dsm23 opened this issue Jan 10, 2025 · 3 comments · May be fixed by #27779
Open

playwright tests have stopped working in deno v2.1.5 #27623

dsm23 opened this issue Jan 10, 2025 · 3 comments · May be fixed by #27779
Assignees

Comments

@dsm23
Copy link

dsm23 commented Jan 10, 2025

Version: Deno 2.1.5

The playwright tests have stopped working for me in my deno template: https://github.com/dsm23/dsm23-deno-vite-spa-template. Specifically, the webServer functionality in the playwright config.

When running locally and running the dev task in a separate window, the tests pass. It seems like playwright is no longer waiting for the command, webServer.command to finish and very quickly says that there is an error connecting to the port, in this case, 5173.

When downgrading to Deno v2.1.4, these tests pass locally and in the pipeline whether playwright is reusing an existing server or not

I am running on a Mac. The GitHub actions pipeline is ubuntu-latest.

@kt3k kt3k self-assigned this Jan 12, 2025
@kt3k
Copy link
Member

kt3k commented Jan 12, 2025

I failed to reproduce the issue locally. When I run e2e task in the above repo, I saw the below error:

$ deno task e2e
Task e2e deno run -A npm:@playwright/test test
error: unexpected argument '--experimental-loader' found

How do you run the playwright test cases? Nevermind. I can now reproduce the issue.

@jaydenseric
Copy link

jaydenseric commented Jan 19, 2025

With Deno v2.1.6 on macOS, trying to launch Chromium with Playwright simply hangs forever, without any errors or console output:

import { chromium } from "npm:playwright@^1.49.1";

console.log("logs");
const browser = await chromium.launch();
console.log("doesn’t log");

Running this beforehand doesn't output any errors:

deno run \
  --allow-env \
  --allow-ffi \
  --allow-read \
  --allow-run \
  --allow-sys \
  --allow-write \
  npm:playwright@^1.49.1 install --with-deps chromium

I've had an absolute nightmare experience trying to get a headless browser setup to run unit tests in a Deno project, all of the things I have tried are horribly broken:

I don't say this to be inflammatory, but I have a business to run: In hindsight I should have spent the several days instead porting the project to Node.js, because now I'm locked into a completely unproductive ecosystem and it seems very unlikely to be functional any time soon :(

I would much rather Deno core team pitch in and smooth out the kinks in the only Deno native headless browser (Astral), than beat about the bush for years on dubious Node.js compatibility to try and fail to get npm packages like playwright and puppeteer working. If I want to use the Node.js ecosystem reliably, why would I be using Deno? I would be using Node.js. Make Deno a good experience and support the Deno ecosystem!

@kt3k kt3k linked a pull request Jan 22, 2025 that will close this issue
1 task
@kt3k
Copy link
Member

kt3k commented Jan 23, 2025

chromium.launch() call seems opening PipeTransport (ipc socket) with chromium process https://github.com/microsoft/playwright/blob/34cb35859aef71fc35f7b8a9dbfe4009c1e64bd5/packages/playwright-core/src/server/pipeTransport.ts#L22

But that doesn't start reading the data from chromium because of a workaround we added in #27662 which pauses the socket at the beginning if the socket is created from playwright-core (the workaround was necessary for TCP/TLS socket, but unnecessary/harmful for Pipe/IPC socket)

I'm trying to fix the issue by adding the check of the socket type (#27779)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants