[Question] Deno Integration?

[DemGiran]

Hello, and congratulations on your project. I see that you are heavily invested in trying to integrate it with platforms other than Node. Thank you for maintaining an official Python repo. Have you thought about Deno? https://github.com/denoland/deno

How about making the npm package play well with skypack.dev? This might make it possible to import Playwright directly from npm? I think there is a potential opportunity there with minimal (if any) additional technical cost. Thoughts?

Thanks for the library! <3

[aslushnikov]

Have you thought about Deno? https://github.com/denoland/deno

@DemGiran we're keeping an eye on deno, but so far there are no plans / user requests to get a better story there.

How about making the npm package play well with skypack.dev?

Out of curiosity, how hard would it be?

[DemGiran]

https://github.com/rollup/rollup/wiki/pkg.module

it needs a web optimized module entrypoint in its package.json manifest

[mxschmitt]

Since we rely heavily on child_process e.g. or other standard Node.js modules we would need to wait until they are available: https://github.com/denoland/deno/blob/master/std/node/README.md
Not sure about other modules tho.

[aslushnikov]

Closing this since there are no plans for this for now.

[shirshak55]

Is the situation still same in 2021? I think deno has improved a lot. And deno security + single binary feature are too good for many people like me to ditch deno.

I hope the decision will be reconsidered in future.

Thanks

[mquandalle]

I’m also interested in Deno support.
Note that there is a fork of puppeteer with Deno support : https://deno.land/x/puppeteer

[josephrocca]

Since we rely heavily on child_process e.g. or other standard Node.js modules we would need to wait until they are available

@lucacasonato Wondering whether you could add a general comment on this, since you wrote the puppeteer port for Deno. Seems like there's support for child_process.spawn. Were there many hoops to jump through while porting Puppeteer?

@aslushnikov Wondering whether this is worth re-opening, or still something to postpone for now?

[ruifortes]

Yeah... let's not stiffen development Microsoft ;-)

[andremarcondesteixeira]

I would love to be able to use Deno with Playwright. Please make it happen!

[trusktr]

I'm looking at the possibility of using puppeteer or playwright as a simple way to make desktop apps with Deno (not for testing). Conceivably, using Playwright's API to control a non-headless browser window would be a good way to spin up a UI for Deno and then passing messages between the browser window and the Deno "backend" (on localhost); basically local RPC calls.

Eventually, someone could provide a carefully crafted importmap.json that can map Deno imports to browser-side shims, and these shims would essentially RPC to the Deno backend. But until then, app-specific messaging would get the job done and it would actually be more secure (a website would not be able to call filesystem APIs even if the Deno backend has those enabled, without having to get permission via communication of some sort).

[mangs]

There are some child_process-releated items here: denoland/deno#12577 (a pinned issue in their repo)

I'm a huge fan of Deno and Playwright, so hopefully a native option comes before that. I mean come on, Deno is even listed on MDN and Web Platform Tests now =D

[chasm]

I, too, would love to see this. Am only waiting on Deno support to begin using and promoting Playwright in all my apps and to all my students.

[christopheragnus]

Hey - just to chime in, I would love to have Deno support as well.

[yeikiu]

+1 for deno integration in case you guys are counting votes. Keep the great work team!

[lino-levan]

I don't have a ton to add to the conversation other than that I would love to have Deno support as well.

[jeroendee]

Deno is an interesting runtime as it is written by Ryan Dahl using his experience regret points from his earlier node.js work.

It appears the deno project has come a long way since this issue has been created.

As of this writing, https://github.com/denoland/deno has reached 85+K stars on Github.

Please re-consider adding support for this runtime.

[tamusjroyce]

` import { chromium } from 'npm:playwright';

(async () => {
const browser = await chromium.launch({
channel: 'msedge',
headless: false,
args: [
//'--remote-debugging-port=8335',
'--disable-web-security',
'--disable-headless-mode'
],
executablePath: 'C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe',
ignoreAllDefaultArgs: true //,
// executablePath: '/usr/bin/microsoft-edge',
//handleSIGTERM: false,
//handleSIGHUP: false
});
const page = await browser.newPage();
await page.goto('http://whatsmyuseragent.org/');
await page.screenshot({ path: example.png });
await browser.close();
})();

export function add(a: number, b: number): number {
return a + b;
}

// Learn more at https://deno.land/manual/examples/module_metadata#concepts
if (import.meta.main) {
console.log("Add 2 + 3 =", add(2, 3));
}
`

I haven't gotten this to work due to SIGTERM or websockets / '--remote-debugging-port=8335' not taking affect. Now that deno is getting npm module support like above, anyone have any luck here?

note: Was trying with wsl2 / linux and windows

[d4h0]

I also tried to get Playwright working with Deno, but didn't succeed.

In case anybody wants to give it a try, here is a snipped:

import { chromium } from 'npm:playwright';

async function main() {
  // const browser = await chromium.connectOverCDP("ws://127.0.0.1:37305/devtools/browser/d8da9c70-6b9c-45a4-8582-c26095adb110");
  const browser = await chromium.launch({
    headless: false,
  });
  const page = await browser.newPage();
  await page.goto('http://example.com');
  await browser.close();
};

if (import.meta.main) {
  main()
}

You can run this via deno run --unstable --allow-all main.ts (this grands the script all permissions, which seems to be a good idea while testing).

The error is as follows:

error: Uncaught TypeError: browserType.launch: Cannot read properties of undefined (reading 'on')
=========================== logs ===========================
<launching> /home/user/.cache/ms-playwright/chromium-1028/chrome-linux/chrome --disable-field-trial-config --disable-background-networking --enable-features=NetworkService,NetworkServiceInProcess --disable-background-timer-throttling --disable-backgrounding-occluded-windows --disable-back-forward-cache --disable-breakpad --disable-client-side-phishing-detection --disable-component-extensions-with-background-pages --disable-default-apps --disable-dev-shm-usage --disable-extensions --disable-features=ImprovedCookieControls,LazyFrameLoading,GlobalMediaControls,DestroyProfileOnBrowserClose,MediaRouter,DialMediaRouteProvider,AcceptCHFrame,AutoExpandDetailsElement,CertificateTransparencyComponentUpdater,AvoidUnnecessaryBeforeUnloadCheckSync,Translate --allow-pre-commit-input --disable-hang-monitor --disable-ipc-flooding-protection --disable-popup-blocking --disable-prompt-on-repost --disable-renderer-backgrounding --disable-sync --force-color-profile=srgb --metrics-recording-only --no-first-run --enable-automation --password-store=basic --use-mock-keychain --no-service-autorun --export-tagged-pdf --no-sandbox --user-data-dir=/tmp/playwright_chromiumdev_profile-2Dn2ZL --remote-debugging-pipe --no-startup-window
<launched> pid=87944
============================================================

I also tried to connect to a manually started Chromium instance.

To give that a try, switch the chromium.connectOverCDP line with the chromium.launch part above.

Take the path to the executable from the error above (i.e. /home/user/.cache/ms-playwright/chromium-1028/chrome-linux/chrome above), and execute the following command:

$executable_path_from_error --user-data-dir=/tmp/foo --remote-debugging-port=0

This will print a line like:

DevTools listening on ws://127.0.0.1:37305/devtools/browser/d8da9c70-6b9c-45a4-8582-c26095adb110

Edit the chromium.connectOverCDP line with that URL.

Run the script again via deno run --unstable --allow-all main.ts.

The error I get is as follows:

error: Uncaught Error: browserType.connectOverCDP: WebSocket error: ws://127.0.0.1:43087/devtools/browser/e5f644e2-da47-4758-9dfe-2848e12a08d5 200 OK
=========================== logs ===========================
<ws connecting> ws://127.0.0.1:43087/devtools/browser/e5f644e2-da47-4758-9dfe-2848e12a08d5
<ws unexpected response> ws://127.0.0.1:43087/devtools/browser/e5f644e2-da47-4758-9dfe-2848e12a08d5 200 OK
<ws error> error WebSocket was closed before the connection was established
<ws connect error> ws://127.0.0.1:43087/devtools/browser/e5f644e2-da47-4758-9dfe-2848e12a08d5 WebSocket was closed before the connection was established
<ws disconnected> ws://127.0.0.1:43087/devtools/browser/e5f644e2-da47-4758-9dfe-2848e12a08d5 code=1006 reason=
<ws error> error WebSocket was closed before the connection was established
<ws connect error> ws://127.0.0.1:43087/devtools/browser/e5f644e2-da47-4758-9dfe-2848e12a08d5 WebSocket was closed before the connection was established
<ws disconnected> ws://127.0.0.1:43087/devtools/browser/e5f644e2-da47-4758-9dfe-2848e12a08d5 code=1006 reason=
============================================================

The Interoperating with Node and NPM section of the Deno documentation might be useful (unfortunately, it doesn't seem to be 100% up-to-date. The --compat flag isn't supported/needed anymore, for example).

[tamusjroyce]

seems like support for SIGHUP and SIGBREAK is supported in libuv. So opened a request inquiring about this effort above. denoland/deno#16298. It may not be a solution to get this running all the way. But at least a step.

@d4h0 I get this as well when I don't use ignoreAllDefaultArgs: true. There are two ways to control chrome/edge depending on how you configure your parameters. websockets or console pipes.

love the callout about websockets, as libuv sets these up different than tokio. So I still believe there is some compatibility between these two libraries that need considered.

[lino-levan]

The Interoperating with Node and NPM section of the Deno documentation might be useful (unfortunately, it doesn't seem to be 100% up-to-date. The --compat flag isn't supported/needed anymore, for example).

According to denoland/manual#408, it looks like they are rewrite the manual from scratch. They do agree that it is confusing.

Also can we get this reopened? This seems to clearly be an active thread.

[tamusjroyce]

I would recommend keeping this closed. playwright is not actively working on a solution. deno itself will be responsible for that solution.

There may be further defects after deno does support playwright. I am wondering if reopening this then. Or a through a new defect.

[woody34]

For anyone that stumbles upon this, it looks like playwright doesn't want to support Deno but Astral exists with a very similar api. It's not as mature as playwright but it is pretty perf.

[ivan-kleshnin]

@woody34 thank you for sharing!

[rsbmk]

thanks @woody34 is very similar api playwirght 🙌