nwhit's comments

nwhit · 2025-05-15T19:04:25 1747335865

I don't think it's that complicated, in my mind it's as simple as the fact that the npm/node ecosystem is huge and not supporting it at all means having to reinvent each and every library that exists there. That is a huge task and in my experience, the lack of support for npm/node packages (used to) really hamper deno's usefulness.

Now you can tap into the npm ecosystem when needed, but still use deno-first libraries as you please. If you don't like npm, then you can ignore it entirely

corytheboyd · 2025-05-15T19:24:50 1747337090

But that’s exactly what I’m saying, a big selling point WAS reinventing things. There would be a stdlib “http” package for all HTTP client needs, an “orm” package, and so on. This is how I remember Deno being sold many years ago, and I thought it was a noble cause.

pier25 · 2025-05-15T19:59:23 1747339163

> If you don't like npm, then you can ignore it entirely

But what if Deno had invested all that Node compat effort into something else?

nwhit · 2025-05-15T18:57:50 1747335470

Jsdom should work in deno, can you open a github issue (https://github.com/denoland/deno/issues) with some details and a reproduction?

All of the simple cases I've tried seem to work fine, e.g:

  import { JSDOM } from "npm:jsdom";
  
  const dom = new JSDOM(
    `<!DOCTYPE html><p>Hello world <img src="https://example.com/logo.svg" /></p>`,
  );
  
  console.log(dom.window.document?.querySelector("p")?.textContent); // "Hello world"
  console.log(dom.window.document?.querySelector("img")?.getAttribute("src")); // "https://example.com/logo.svg"

MrJohz · 2025-05-15T19:25:14 1747337114

Earlier today, it was producing an error that looked as if it couldn't render some elements. Unfortunately, I switched to a different branch where I tried to switch certain things over to Node, and now when I've switched back, there's a different error, now in the `readability` module, but still connected to its use of jsdom. It looks like it could be due to version mismatches — maybe readability requires a different version of JSDOM to the one installed by default — but now I'm trying to downgrade the currently installed version of JSDOM, and that doesn't seem to work — the version in deno.lock is stubbornly staying at the later version, despite having specified an older version in the `deno.jsonc` (and that older version appearing in the `workspace.dependencies` array at the bottom of the lock file).

I'll try again with a clearer head tomorrow, and maybe if I figure stuff out I can create a proper reproduction, but right now I don't know how to reproduce anything because it doesn't seem like my local environment is consistently reproducible, let alone trying to create something that would work on other machines. I'm surprised at how poor this behaviour is — I thought a big part of Deno@2 was to fix these sorts of dependency issues.