Hacker News new | ask | show | jobs
by notnullorvoid 27 days ago
A lot of these changes seem geared toward adopting Node/NPM default DX. To the point where Deno DX (or what it was previously) now comes second.

The worst of the changes is "lib.node included by default", if I'm writing Deno or web code I absolutely don't want node types included by default. Those types were a pain to deal with even in Node projects, resulting in multiple tsconfigs to avoid those types polluting platform agnostic or web code.

If Deno continues this trajectory then there is less and less reason to use it over Node.

2 comments

Bartek from the Deno team here. Thanks for the feedback, I understand your frustration.

> The worst of the changes is "lib.node included by default", if I'm writing Deno or web code I absolutely don't want node types included by default.

Since a few versions ago, Deno now has some of Node.js APIs included by default (eg. process or Buffer). It's really more of a bug fix to make type-checking work properly.

While it's not ideal, you can still decide which types you want included by default with `compilerOptions.types`. `["deno.ns", "web"]` should give you what you're looking for.

I somewhat agree with you.

For example, in Deno v2.8 they've changed the return type of setTimeout and setInterval functions from webstandard-compliant 'number' to opinionated 'NodeJS.Timeout'. Which is a short-sighted change trying to reap immediate short-term implementation-centric benefits in the expense of the future. Pains of churn and breaking API changes are welcoming their new bearers...

Bartek from the Deno team here. Thanks for the feedback. I assure you this is not a short-sighted change. This has been a problem since before Deno 1.0. We resorted to hacks like different set of globals for user code and different for code inside node_modules/ directory. It was a maintenance headache, made global lookups super slow and was really hard to explain to users. While Web "setTimeout" might have been nice in the beginning the fact that it required additional APIs like "Deno.unrefTimer" made it worse than Node's setTimeout.