Hacker News Reader

Comment by wrnr | Hacker News Reader

Deno uses ES modules and has a build in TypeScript compiler and solves these issues. Just be careful when using different versions of different packages and always use the same version of a service like esm.sh that translates CommonJS modules to ES modules, it has a versioned API so esm.sh/v70/lodash@1.2 != esm.sh/v71/lodash@1.2. I hit my head on this problem for a couple of days.

View on HN

But Deno is incompatible with npm, no? Deal breaker.

https://deno.land/manual/node#interoperating-with-node-and-n...

No it is not, that it what the esm.sh is for. It transforms a npm package into a ES module. Just make sure that when you have the dependencies A@2 and B@1 where B@1 depends on A@1 (in package.json) then you end up with 3 dependencies A@1, A@2 and B2 which results in bugs if your code expect the versions of A to match. Similar for using the same version of A but a different version of the api like esh.sh/v10/A@1 and esh.sh/v11/B@1 this will result in esh.sh/v10/A@1, esh.sh/v11/A@1 and esh.sh/v11/B@2.

Why does it matter? Deno should not need NPM in any capacity, or does it?

Because npm is the biggest repo in the history of computing and Deno makes it redundant. The people at Jetbrains knew about backwards compatibility when they created Kotlin. It's too late to just ditch npm.

Not quite sure why you shouldn't be able to create a proxy service that serves NPM packages in a form that Deno can consume if you feel the overwhelming need to use NPM packages. (I don't, personally, but tastes differ, I'm sure.)

Reply on news.ycombinator.com