Left pad was promptly fixed! That's an argument for a centralized package manager, not against. If it were hosted on some private server we'd all still be screwed.
How is that important? Most Deno packages are imported from GitHub (or deno.land). Neither NPM nor GitHub want to lose your code.
> Left pad was promptly fixed! That's an argument for a centralized package manager, not against.
This is not an argument for a central package manager, but an argument for a central package repository.
Deno is already a "central package manager". Similar to NPM in Node development, Deno is the default tool to download code in Deno development. Both with Node or Deno, you can download code in other ways, too. Nobody forces you to load code from URLs via import statements or NPM packages via npm install and commonjs require. (Also, when it comes to executing random code from the internet, Deno has a sandbox. Node doesn't.)
And yes, well maintained package repositories are great. Whether centrally or decentrally managed repos are better is up for debate, though.
In any case, if you want to use NPM packages in Deno, I'd recommend https://www.skypack.dev/. It's "NPM packages from a URL", so, as we have established earlier, it's just as much reliant on trust and potentially unstable as anything in life, but at least their left-pad is patched...
Import maps allow you to do that, see: https://deno.land/manual/linking_to_external_code/import_map...
Also, it seems as though ./node_modules/ being the default could be assumed automatically though, no?
"imports": {
"moment": "/node_modules/moment/src/moment.js",
"lodash": "/node_modules/lodash-es/lodash.js"
}
No, there is no magic node_modules directory in any other JS environment, other than Node. Deno aims to be compatible with web standards. Import and import maps are web standards, require and node_modules aren't.
> Deno would be a drop-in replacement and we could move our whole codebase over to it overnight
The reason that you cannot move your existing codebase to Deno tonight is essentially the poor web compat of the existing Node ecosystem.
I don't think you can blame the incumbent tool with complete market dominance for "poor compatibility"...
I really like the direction of the Node compatibility layer though https://deno.land/std@0.80.0/node, I suspect it will be enough to make Deno a drop in replacement soon. Now it just needs support for normal `import` statements from node_modules instead of just `require()`.
How dare Node not be compatible with the market dominating jQuery! Silly server-runtime not having a browser window object!
> Now it just needs support for normal `import` statements from node_modules
Deno will never ever do that (other than by using standardized import maps) since that's not normal (normal meaning standardized).
import $ from "jquery"
Why would Deno take such an antagonistic approach to supporting the most common setup that everyone uses with npm? Wouldn't it be trivial to just fall back to checking node_modules for named packages? I want to use Deno! This seems like it's deliberately making transitions difficult for anyone using npm.
The fact remains that the most popular JS env is the browser. It has APIs such as window which are not compatible with Node and Node has APIs which are not compatible with the browser like __dirname or require. That's why tools such as browserify and webpack exist to bridge the gap.
In Deno the gap is much closer. Obviously, the Deno namespace is not available in the browser (but there's a shim for most APIs, e.g. Deno.writeFile and readFile are implemented with a virtual FS) and some web APIs are not available in Deno (yet), but the compat story is much better.
This is no surprise since web compat is a core goal of Deno. Node compat is not.
> Wouldn't it be trivial to just fall back to checking node_modules for named packages?
No, the resolution algo is not trivial (nor performant). Also, it's not necessary: There is already a standard for how to import code in JS; it's import statements. Import statements do not allow named packages, e.g. import $ from "jquery" does not work in the browser. Except, again, import maps.
:'( That's a shame, it would make such a good node replacement with a great stdlib and Typescript support. I hope they reconsider in the future.
These (and other) disruptive breaking changes are about fixing mistakes that cannot be fixed (or at least, are hard to fix) in Node.
Maybe, in a few years, you'll say something like "Oh, I wish legacy Node would be more Deno compatible" because Deno will be the de-facto server-side JS scripting runtime. Equally, it's possible that Deno will fail, but that many good ideas will be incorporated into Node as breaking changes.
Node and Deno as well as their environments can grow further together or further apart. I think it's too early to tell which future is more likely.