Deno 1.31: Package.json Support | Hacker News Reader

Deno 1.31: Package.json Support

deno.com

114 pointsmikece45 comments

Hallelujah, I've been waiting for this for years. This was the one remaining thing I needed to transition to Deno.

I got SO MUCH pushback every time I asked for this. Everyone on the Deno side was so righteous / moral high groundy about not adding package.json support and swore up and down that they never would because it goes against the entire ethos.

I knew they would eventually cave and implement it, but I will hold my tongue on any further snark and just be appreciative that it's finally here, and thankful for all the hard work they put into implementing this difficult compatibility layer! ;)

It could become a mediocre project from now on. It's becoming a marginal improvement over Node at best.

...because it added package.json support?

Because it caved in in a core principle, which was to be a zero configuration JavaScript/TypeScript runtime environment.

I don't use Deno. I'm making a thought exercise :)

You don’t need an import map on an existing project now, meaning it needs less configuration than before.

When were import maps ever necessary? Pretty much every Deno project I've seen uses `deps.ts`. Only reason for import maps most of the time is for vanity module names, unless I'm mistaken.

They were useful for getting URLs out of your source code, which are inherently brittle.

Isn't that exactly what a deps file does? Technically it's code, but it's serving the same purpose of keeping the URLs in one place. It seems like the only unique function that import maps serve in Deno is so that, instead of importing from "./deps.ts", you're importing from arbitrary identifiers. Which is fine, but I wouldn't say that import maps are ever needed in Deno. It was always possible to organize dependencies in a TS/JS file and import from its module.

The issue is that being code it's turing complete and not parsable by other tooling easily. Having it in a config format (yaml, json, etc.) is easier for other tooling to inspect.

infrastructure as data > infrastructure as code

One of the reasons behind ES module syntax was to make imports/exports statically analyzable. Sure, it's technically simpler and more portable to use JSON, but a tool that fits all more use cases isn't necessarily the best tool for the most common use cases. Given that all import maps are just maps of names to URLs, I see no reason why a JS module couldn't be trivially parsed to inspect what URLs are being imported and what identifiers are being exported.

This doesn't take into account how much tooling is not written in JS. There are lots of ecosystem tools implemented in rust, C++, bash, python, etc. that parse dependencies for things like CVE checking, version bumping, dependency graph analysis, etc. that don't want to have to implement a full JS runtime to get the list of deps. Python has requirements.txt and pyproject.toml, Rust has config.toml, etc. many languages keep their project metadata and dependencies in config formats instead of code for good reasons.

Why would you need a full JS runtime just to analyze what URLs are being imported? You don't even need a runtime for that. All that's necessary is to parse the AST, and in that case you don't even need an AST parser with full language support. It might not be as trivial for other language communities as writing a JSON parser, but it's not insurmountable or an unreasonable burden.

Honestly, I think the argument that one language community should lessen itself for the sake of another really bites. Using one language to analyze the dependencies of another really isn't a garden variety task. In the off chance someone really doesn't want to use JavaScript as their primary language for that task, what's so bad about calling an external runtime or parser from their language of choice?

I'm not saying I'm against import maps, because I think it's absolutely reasonable to want the features it provides, but I'm not being sold on any argument that they're necessary for almost anything. There's not a type of application I can think of that can't be written without anything an import map does.

I think your claim, that the Deno community is in some way "lessen[ing] itself" with this change, requires more explication than you've given it, not least because it's far from clear that providing a relatively straightforward onramp for existing projects and teams from Node to Deno will have any such effect.

Strong disagree, Deno gets so many things right that are really different from Node, package.json is just a small piece. A compatibility layer to allow large projects to migrate doesn't compromise Deno's principles as long as they don't change the Deno docs to point greenfield users towards package.json by default.

Marginal improvement? Uhh, for a greenfield deno project it's light-years more productive than node and npm. You directly import dependencies by URL and never have to touch or know about a package manager, node_modules folder, etc. You have a fully featured standard library and don't have to download third party code for stuff like left padding a string. You have typescript transpilation out of the box and with zero config vs. sometimes hours of fiddling and fuss with node. You have ES modules by default and none of this nonsense about .cjs vs. .mjs etc. It's a much more opinionated ecosystem and that's a good thing IMHO.

I think people mad about this and node support in general don't realize it's just a quality of life thing for people moving existing code over to deno. Instead of being like python 3 that firmly said "just rewrite your code, stop complaining" the deno folks are giving people an easier way with compatibility to node.

Not sure what's more impressive. You holding out for years for this feature or Deno's implementation.

It was kind of a show-stopper missing feature if you had a large JS project with many NPM dependencies that you wanted to migrate slowly to Deno.

I was not their target demographic before, but I'd guess this means things are changing as they want to scale and gain mass adoption, which sometimes takes bending principles to build a better compatibility and transition UX.

For the record I'm really not asking them to favor package.json or even document it that well, they should still push new users towards the awesome Deno principles that get the industry away from NPM dependency hell. I just think compatibility layers are important for mass adoption, and don't necessarily imply Deno is "compromising" on their principles.

> I knew they would eventually cave and implement it […]

Let’s see how long it takes until Deno is just NodeJS Mark 2, with little value of adopting it.

Hopefully the answer is never, but considering the type checking changes last year and deprecation of bundle now I have little faith that the features that, at least to me, made Deno a worthwhile improvement over NodeJS will stay.

I can't say I appreciate adding package.json support, but I also don't see it as necessarily a bad thing.

In my opinion, it would be a bad thing if this encouraged everyone to start using Deno as a stand-in for Node and make more Node patterns typical in Deno development. If package.json is there merely for backwards compatibility then that's one thing. On the other hand, if things drift towards doing everything the Node way again... well, I'm sure there's someone this very moment writing a "better" package manager for Deno that "solves everything for real this time." And I don't look forward to the flurry of package managers for Deno. Who's ready to decide whether "nary" is better than "dpm" or "pdpm"?

Exactly, I hope Deno gaining mass adoption will move the industry away from NPM dependency hell.

This is just a stepping stone to get more projects on board with that mission by giving them a practical migration path from the old system.

> it would be a bad thing if this encouraged everyone to start using Deno as a stand-in for Node and make more Node patterns typical in Deno development

It’s hard to see how adding package.json and the node compatibility layer is not going to make this like pypy.

Ie. Highly compatible, technically distinct, practically irrelevant and not quite perfect dropin replacement for just using node to run your “designed for node” code.

For one pypy doesn't offer an entirely new security model or standard library that displaces hundreds if not thousands of old 3rd party packages.

Deno fans, how are you using this language?

I think they have some interesting ideas, but it increasingly just integrates Node.JS features, and from a casual observer's viewpoint I'm not entirely sure I understand what their initial goals were and if they have drifted far from them. It looks like compromised principles from where I sit, which can often be a bad thing - especially because package.json was one of the best parts of NodeJS and so it looks like their principles were made without a plan.

Thoughts?

Start off by doing things the deno-"native" way and it's very fun. Most or all of the js tooling woes go away. It starts as just a .ts file that works. I love it for small CLI utilities. There are some quirks[0] but it's well designed UX overall.

Stuff like node stdlib support is a necessary evil for some things. Like sharp (libvips binding) and nestjs didnt work at all before that iirc. And alternatives a lot of work to make.

0: https://github.com/denoland/deno_std/discussions/2102

> especially because package.json was one of the best parts of NodeJS and so it looks like their principles were made without a plan

Yes, that's very much my impression as well. Their approach to package management feels very much like throwing out the baby with the bathwater. Sure, it's nice to naively import your dependencies from some random URL like it's 2005, but there is a good reason why the JS ecosystem at large has moved away from that. And while the npm ecosystem has some problems, npm (and preferably pnpm) is a package manager of a quality that few other programming languages have.

Deno seems like a nice "fun" runtime for throwaway weekend projects, but most of the things that make it "fun" come from ignoring complexity that will fall on your feet once you try to do anything more sophisticated.

I still have never understood why people consider the lack of package management in Deno a plus. It sounded interesting to me when I very first watched the deno sales pitch back in the day. But when I tried to use it for something non trivial it was so clearly worse to me. To each their own I guess

Deno doesn't lack package management, but it does lack a CLI like npm. There are community CLIs (like trex), however.

> Sure, it's nice to naively import your dependencies from some random URL like it's 2005, but there is a good reason why the JS ecosystem at large has moved away from that.

That's not what you do with Deno in practice, though. Typically, you'll import modules from a trusted registry like deno.land/x/ or esm.sh. The nice way about how Deno handles modules is it becomes dead simple to host a private registry. Also, if anything, JS has moved toward this because this is how ES modules work in the browser (which Deno tries to emulate).

> Deno seems like a nice "fun" runtime for throwaway weekend projects, but most of the things that make it "fun" come from ignoring complexity that will fall on your feet once you try to do anything more sophisticated.

I don't buy this on account of several folks are already using Deno in production, and from my own experience, Deno Deploy was insanely easy to become productive with. Can you be more specific on how Deno ignores complexity? On the topic of package.json, I feel most of its utility can be replaced by import maps and deno.json.

> Typically, you'll import modules from a trusted registry like deno.land/x/ or esm.sh.

Great, with that we've already tremendously increased the attack surface of supply-chain attacks for your normal copy-past install, and moved it into an entirely unmoderated space (unlike npm, which has a process for reporting and removing malware[0]). E.g. there is nothing preventing someone from buying a typo version of those domains (like deon.land, which I just bought), and distributing those to users and have them install malware.

E.g. add `import * as flat from "https://deon.land/x/flat@0.0.15/mod.ts";` (or any other deno->deon changed import) to your file, and see what happens.

> The nice way about how Deno handles modules is it becomes dead simple to host a private registry.

There is more to running a registry than just exposing files. And if you want a similarly simplistic registry for NPM, I don't think NPM will prevent you from using the URL of a packages .tar.gz.

> several folks are already using Deno in production

Just because _some_ people are using it in production doesn't mean it's a good idea. And for many of those projects, you are basically sacrificing ecosystem access. While I'm all for reducing your dependency tree, I know that I wouldn't want to build a project without access to most of them.

> Deno Deploy was insanely easy to become productive with

So are most edge computing focused solutions nowadays. Cloudflare Workers, which I used for the deon.land gag also only took me 5 mins to set up from scratch.

> Can you be more specific on how Deno ignores complexity?

Apart from the things above, just take a look at any discussion about supply chain security (especially the major incidents) of the last few years and ask yourself "Does deno have measures to prevent them?", and you'll end up answering most of them with "No".

And that was mostly done in the name of simplicity, to help onboarding new developers, with no consideration to what can (and will) happen to the users of those services once they make it into production.

While Deno is now adding parts of those features, it is an all aspects still trying to peddle it's simplistic alternatives, and is breeding a community, that want to have it in that insecure way. That's incredibly worrying to me.

[0]: https://docs.npmjs.com/reporting-malware-in-an-npm-package

> Great, with that we've already tremendously increased the attack surface of supply-chain attacks for your normal copy-past install, and moved it into an entirely unmoderated space (unlike npm, which has a process for reporting and removing malware[0]). E.g. there is nothing preventing someone from buying a typo version of those domains (like deon.land, which I just bought), and distributing those to users and have them install malware.

This is a price of the inherent decentralized idea that the Deno team has. I foresee tooling or other forms of validation in the future to prevent things like this, but until then, just as a team requires discipline to not do things like blindly updating all of their ^ dependencies in Node world, `npm install`ing a package with a gigantic and risky dependency graph, deleting the lockfile, or mistyping the name of a package (`npm install reactt`), some degree of discipline is necessary with Deno as well.

> Just because _some_ people are using it in production doesn't mean it's a good idea.

Maybe their use cases are different than yours, and maybe the benefits of Deno outweigh the negatives given their circumstances! The ecosystem argument is always silly because if X is popular before Y is, X will have a more vibrant ecosystem. Deno apparently has npm interop, though, I have not used it.

> So are most edge computing focused solutions nowadays. Cloudflare Workers, which I used for the deon.land gag also only took me 5 mins to set up from scratch.

I am also a fan of Cloudflare Workers. That doesn't change the fact that I am still productive with Deno Deploy.

> Apart from the things above, just take a look at any discussion about supply chain security...

Thanks, but this is not a specific answer.

> It looks like compromised principles from where I sit, which can often be a bad thing

Or they're not fundamentalists.

I don't like package.json either, but I couldn't care less if it gets more people using Deno.

> I don't like package.json either

I think you're seeing it from the wrong perspective.

I, as an ardent NodeJS user (hooray UI development), think NodeJS has a lot of problems. Less now, but a lot. Any list of pros and cons for NodeJs looks a bit like this:

Pros: * Package management Cons: * JavaScript

The fact that the deno guys were like "yeah, this whole NodeJS thing sucks, let's throw it all out", only to never have an answer for easy package management, looks incredibly foolish from my perspective. NodeJS might be the single best language for package management today.

I agree with the point that adding support for it is pragmatic, but I am asking the question: how was such a pragmatic thing thrown out in the first place for "principled" reasons? Those principles look very foolish to me, both then and especially now.

The problem is that npm package management is so stupidly easy that it creates other problems like dependency creep and supply chain attacks. Perhaps the Deno team wanted to do away with this but could not or maybe bother with it later on.

This feature created a lot of debate [0]. However, I think it is a good thing to ease transition. I could also appreciate that Deno accepts importing ts files from a js extension. This could make Deno compatible with regular bundlers such as esbuild.

[0] https://github.com/denoland/deno/issues/17491

Downgrading the user experience of native deno users for the sake of nodejs compatibility is a huge bummer.

Deno bundle was really really nice, and often times good enough for browser deploys.

All the recent Node-related features are bound to alienate their core audience but I wonder to what extent.

What are the drawbacks of these changes? I haven't been following deno very closely.

IMO the appeal of Deno was an opportunity to rethink the JavaScript ecosystem. The introduction of all these Node features make it far more likely that things stay the same way they currently exist with Node, making it feel pointless to bother with Deno at all in the first place.

Is package.json required?

Not required, but perhaps contagious

This is a valid concern but I think they can mitigate it with social pressure, documentation, and public success stories from users that fully eschew the old system.

Hopefully not everything has to be as contagious as POSIX compatibility was for OS's.

except that if deno fails because its uptake cost makes it hard for engineers to sell to their org, what does it accomplish then? At least if it's getting used heavily people can invest engineering effort into the ecosystem on company time.

Does every project need to strive for maximum adoption? I guess because Deno is a company the answer is yes.

But I think one of Deno’s initial appeals was “A JS/TS runtime for people that don’t want to deal with JavaScript status quo”. Its accomplishment would have been to be bold and try something different, similar to for example Zig.

Almost a year ago with Deno 1.22 type checking for TypeScript was default disabled. (i.E. you must manually request checking on the CLI, editors still do typechecking as before)

At least in my microcosm of Deno-use the package quality degraded since then with more and more packages having subtle type bugs that could have been caught easily by anyone with checks enabled.

Compared to what was before that is to me a drawback, but of course it depends on whether your bigger priority is to reduce friction.

Apparently `deno bundle` has now been deprecated too, because it couldn’t be used for web bundling and because NodeJS support is hard.

So early adopters that possibly wanted to get away from the web and NPM get punished by these ecosystems now.

Hope my 2 cents answer your question.

The solution to this is socially-enforced, like it is for most questions of best practices, code style, etc.

Reply on news.ycombinator.com