I get the reason for this, but am a little bummed. Deno was a great chance to step away from the tirefire of the NPM/node ecosystem and start fresh.
We want Deno to be accessible and solve people’s problems
…so they have decided to reintroduce all of the problems of the packages on NPM. T_T
I know it’s a little heavy-handed, but forcing people to bring over the stuff they actually care about to a better language (Typescript) is maybe the right answer.
I agree. There is simply so much crap on npm that nuking it and forging a new path appears the preferable option - I suppose a lack of meaningful uptake due to reliance on npm packages forces this, but still, it is a disappointment.
As of now Deno has no package manager and unsafe defaults for third party dependencies, including resolution (via DNS!) and linking at runtime. NPM at least locks dependency versions by default and offers protection against takeover attacks in addition to offering a way to automate dependency updates.
Whatever problems exist with NPM aren’t solved by going backwards in time instead.
Seems like all the hype about bun.sh’s speed got them worried. I would imagine they were planning on working on the performance, but sounds like it got kicked into gear:
We know there’s been a lot of chatter recently about runtime speed. Competition is good for the ecosystem!
We’ve been working on some updates that will allow Deno to easily import npm packages and make the vast majority of npm packages work in Deno within the next three months.
On the one hand, good on them for recognizing a major limitation and doing something about it. On the other hand…
import express from "npm:express@5";
This syntax introduces yet another module resolution algorithm in addition to and incompatible with the ones that already exist in:
The browser spec
Node
webpack, Vite, and other bundlers and build tools
The TypeScript language server
I’m sure they’d like to avoid reinventing package.json, but it seems like there ought to be someplace outside of the source where package installations can be managed instead of hacking npm into the module name.
I don’t see it THAT bad… it builds on the same logic as the node:xxx modules in Node.js. That is the closest to a standard in regard to backend JavaScript.
but it seems like there ought to be someplace outside of the source where package installations can be managed
I agree 100%. But that’s sort of a fundamental issue with Deno’s whole approach. In reality, it’s extremely useful to use abstract package names in the source and provide a mapping between abstract package name and concrete package implementation externally. Deno’s (and Go’s) rejection of that idea is unfortunate imo. Go has mostly reversed their direction, where the import URLs are now abstract package identifiers which are resolved using go.mod; maybe Deno should do the same.
Yeah, like: one thing that really confused me was why they didn’t do something like import express from npm("express@5"), which, although I suspect (honestly, I think) isn’t technically a valid import syntax, has the benefit that it could simply expand out to e.g. https://esm.sh/express@5, and therefore keep the existing, clean import system Deno already has.
I feel for Deno. They’re between a rock and a hard place on innovating v. breaking all backwards compatibility. But I feel as if this is a small step in the wrong direction that’ll be very, very hard to unwind from.
I get the reason for this, but am a little bummed. Deno was a great chance to step away from the tirefire of the NPM/node ecosystem and start fresh.
…so they have decided to reintroduce all of the problems of the packages on NPM. T_T
I know it’s a little heavy-handed, but forcing people to bring over the stuff they actually care about to a better language (Typescript) is maybe the right answer.
Those systems never get used at dayjobs, and never provide an upgrade path for people trying to get off the legacy platform.
You need an upgrade path from the old thing to become dominant.
I agree. There is simply so much crap on npm that nuking it and forging a new path appears the preferable option - I suppose a lack of meaningful uptake due to reliance on npm packages forces this, but still, it is a disappointment.
I suppose nothing forces to use that when you don’t need it. But it might be handy for when it is required to get a job done fast.
I dunno, not having a package management story at all is its own tire fire waiting to happen.
What do you mean by package management story?
As of now Deno has no package manager and unsafe defaults for third party dependencies, including resolution (via DNS!) and linking at runtime. NPM at least locks dependency versions by default and offers protection against takeover attacks in addition to offering a way to automate dependency updates.
Whatever problems exist with NPM aren’t solved by going backwards in time instead.
Seems like all the hype about bun.sh’s speed got them worried. I would imagine they were planning on working on the performance, but sounds like it got kicked into gear:
On the one hand, good on them for recognizing a major limitation and doing something about it. On the other hand…
This syntax introduces yet another module resolution algorithm in addition to and incompatible with the ones that already exist in:
I’m sure they’d like to avoid reinventing
package.json, but it seems like there ought to be someplace outside of the source where package installations can be managed instead of hacking npm into the module name.I don’t see it THAT bad… it builds on the same logic as the
node:xxxmodules in Node.js. That is the closest to a standard in regard to backend JavaScript.I agree 100%. But that’s sort of a fundamental issue with Deno’s whole approach. In reality, it’s extremely useful to use abstract package names in the source and provide a mapping between abstract package name and concrete package implementation externally. Deno’s (and Go’s) rejection of that idea is unfortunate imo. Go has mostly reversed their direction, where the import URLs are now abstract package identifiers which are resolved using go.mod; maybe Deno should do the same.
Deno does have a go.mod equivalent: https://deno.land/manual/linking_to_external_code/import_maps
(This is a standard and was not invented by Deno. https://wicg.github.io/import-maps/)
As well as a lock file for integrity checking: https://deno.land/manual/linking_to_external_code/integrity_checking
(This is Deno-specific)
Yeah, like: one thing that really confused me was why they didn’t do something like
import express from npm("express@5"), which, although I suspect (honestly, I think) isn’t technically a valid import syntax, has the benefit that it could simply expand out to e.g.https://esm.sh/express@5, and therefore keep the existing, clean import system Deno already has.I feel for Deno. They’re between a rock and a hard place on innovating v. breaking all backwards compatibility. But I feel as if this is a small step in the wrong direction that’ll be very, very hard to unwind from.