Deno: jsdom Port for 1.0 (Feature Request)

[David-Else]

@MarkTiedemann I was wondering if the jsdom port is still happening? I see it was never merged: https://github.com/denoland/deno_std/pull/542

It would be amazing to be able to test code for the browser in Deno 1.0. Thanks!

[MarkTiedemann]

@David-Else To be honest, I just forgot about the PR. It was blocked by missing support for .d.ts files. As far as I know, Deno does support those type declarations now. Even then, there might still be some issues with the browser Window type being different than Deno Window - but hopefully nothing blocking a preliminary implementation that could be merged and refined later.

I currently don't have time to work on this. If anyone wants to pick up this issue, I'd highly appreciate it. :)

Also, not sure whether this belongs in deno/std or whether this should be a userland thing..

[David-Else]

I regret that at this point in time I don't have the knowledge needed to work on this, but fingers crossed someone reading this will :)

[David-Else]

@MarkTiedemann I am trying to use normal jsdom with deno and can't get it working as it is not compatible with es modules. import jsdom from "jsdom"; gives error: Uncaught ImportPrefixMissing: relative import path "jsdom" not prefixed with / or ./ or ../ Imported from "file:/// ...". There seems to be no file with an export to import from.

I have been struggling to use jsdom for my tests for what seems like forever now. Is there some simple solution to use jsdom in deno that you happen to know of? Cheers!

[MarkTiedemann]

I used webpack-cli to bundle up jsdom (see: https://github.com/MarkTiedemann/deno_std/blob/port-jsdom/jsdom/webpack.config.js). The resulting file starts like this: var jsdom=function(e){.... To use it with ES Modules, I simply used sed -i.bak '1s;^;export ;' ./vendor/jsdom.js to prepend export so it says export var jsdom=function(e){... (see: https://github.com/MarkTiedemann/deno_std/blob/port-jsdom/jsdom/package.json#L3).

Hope this helps.

If you want to give this PR a shot, feel free ask for help. :)

[ak-1]

@MarkTiedemann: I just tried it out. This is very cool!
I had one issue though: deno example.ts failed with this message:

error: Uncaught ImportPrefixMissing: relative import path ",y),_null:E(" not prefixed with / or ./ or ../ Imported from "file:///home/.../jsdom/vendor/jsdom.js"
► $deno$/dispatch_json.ts:40:11
at DenoError ($deno$/errors.ts:20:5)
at unwrapResponse ($deno$/dispatch_json.ts:40:11)
at sendSync ($deno$/dispatch_json.ts:67:10)
at resolveModules ($deno$/compiler_imports.ts:71:10)
at processImports ($deno$/compiler_imports.ts:166:27)
at processImports ($deno$/compiler_imports.ts:175:13)

If you search for ",y),_null:E(" in vendor/jsdom.js you find this:

...,_import:E("import",y),_null:E("null",y),...

Somehow deno parses the "import" as an import statement.
To fix this I changed the quotes around import from double to single quotes.

[David-Else]

@ak-1 Someone was trying to use JSDOM with import jsdom from 'https://dev.jspm.io/jsdom' and it did not work:
https://github.com/denoland/deno/issues/3852

and it just got fixed and added:
https://github.com/denoland/deno/pull/4030

maybe the next version of Deno will support JSDOM through dev.jspm.io? I just saw the commits. I have not tested anything. Fingers crossed :)

[bartlomieju]

@David-Else that's correct, with #4030 I'm able to deno fetch -r https://dev.jspm.io/jsdom, but there are some more quirks (possible just TS config needs to be adjusted).

[kitsonk]

Also, #4040 helps get a step further, but there is a dependency in there what has some jspm import syntax which we don't support in Deno.

[avindra]

Tried this:

// app.ts
import jsdom from 'https://dev.jspm.io/jsdom'

console.log('its',jsdom);

It fails here:

$ deno app.ts 
This browser lacks typed array (Uint8Array) support which is required by `buffer` v5.x. Use `buffer` v4.x if you require old browser support.
error: Uncaught TypeError: buf.write is not a function
► https://dev.jspm.io/npm:@jspm/[email protected]/nodelibs/buffer.js:458:22

458     var actual = buf.write(string, encoding);
                         ^

    at fromString (https://dev.jspm.io/npm:@jspm/[email protected]/nodelibs/buffer.js:458:22)
    at from (https://dev.jspm.io/npm:@jspm/[email protected]/nodelibs/buffer.js:339:14)
    at Buffer (https://dev.jspm.io/npm:@jspm/[email protected]/nodelibs/buffer.js:322:12)
    at https://dev.jspm.io/npm:@jspm/[email protected]/nodelibs/crypto.js:14575:26
    at dew$1N (https://dev.jspm.io/npm:@jspm/[email protected]/nodelibs/crypto.js:14574:27)
    at dew$1W (https://dev.jspm.io/npm:@jspm/[email protected]/nodelibs/crypto.js:15329:14)
    at https://dev.jspm.io/npm:@jspm/[email protected]/nodelibs/crypto.js:15380:20

[kitsonk]

@avindra this was due to #4721 which was fixed upstream. Tested working with recent releases of Deno.

[kitsonk]

(also JSDOM from JSPM seems to load now fine under Deno. I haven't tried it with loading types though)

[axetroy]

@David-Else

The module output by jspm is working fine.

there is no declaration file. so all is any

edit:
The current trouble that hinders the use of jsdom is the declaration file

Declaration files that depend on libraries are relatively easy to migrate

The problem is with lib.dom.d.ts because it has a duplicate declaration withDeno.d.ts

[David-Else]

@axetroy I have my eye on https://deno.land/x/types/ , but ideally Pika would ship JSDom with the X-TypeScript-Types header... but how to stop it conflicting with Deno.d.ts I don't know. It is all a bit confusing at the moment, would be great to see something in the manual about these issues.

[Pierstoval]

Hey folks! Any move on this? Is there anything else that has been tested?

I'd like to contribute on this specific field, so if I could help, please ping :)

[kitsonk]

@David-Else @axetroy I think we are really down to one conflict (see #5365), but it feels like we should really just eliminate any conflicts. We don't really want any.

[Pierstoval]

As for the record, I took back @MarkTiedemann's work and updated it just a bit, especially adapted tests to the new Deno tester, if you think I can make a PR: https://github.com/denoland/deno/compare/master...Pierstoval:jsdom

[MarkTiedemann]

I'm not sure this is needed anymore. The basic jsdom functionality of DOM parsing works for me out of the box now:

import jsdom from "https://dev.jspm.io/jsdom";
console.log(
    new jsdom.JSDOM("<h1>Hello, World!<h1>", { url: "https://localhost" })
    .window.document.querySelector("h1").textContent
); // => "Hello, World!"

[Pierstoval]

Is it okay for the Deno ecosystem to rely that much on the JS one? I would rather implement a stand-alone version of it, could it be internal to Deno, or a specific Deno-compatible version of the original package, WDYT?

[MarkTiedemann]

Is it okay for the Deno ecosystem to rely that much on the JS one?

Yes. Deno is a JS runtime. It would be sad if it was not compatible with the existing JS ecosystem.

[Pierstoval]

I was meaning the Node.js one, specifically, but I get your point :)

[hayd]

Perhaps this should be an example in the docs/manual ?

I think the part that will be strange/legitimate grievance here: is where will documentation live for https://dev.jspm.io/jsdom, presumably the README will not say anything about deno! 😕

(But this is _very_ cool!)

[MarkTiedemann]

where will documentation live for https://dev.jspm.io/jsdom

Maybe https://deno.land/x/jsdom?

Don't think this needs to be in std.

[ry]

closed in favor of https://github.com/denoland/deno/issues/6794 - more specific