Deno 1.34: Deno compile supports NPM packages

by unripe_syntax • 3 years ago

271 89 3 years ago

Etheryte• 3 years ago

I'm very happy with the direction Deno is taking in its development. At the same time, I'm not sure when I would feel comfortable deploying something to production with it. Is anyone here running Deno in production?

tmikaeld• 3 years ago

Why wouldn't you be comfortable with running it in production?

Just don't use the parts labeled as "experimental" or "beta" and it's very production-ready and stable.

yCombLinks• 3 years ago

Because things like adoption and longevity of a project correlate with it not being abandoned, etc. Dealing with abandoned tech in your stack sucks

chrisabrams• 3 years ago

I have a small Deno powered bot that generates Shopify listings from some inputs. It’s been running for a few months with no crashes or restarts.

I think it really comes down to what APIs or packages you need. I have had trouble with projects such as Prisma and wouldn’t do that in production as the generated output is slightly different for some reason (haven’t had time to inspect).

quentinadam• 3 years ago

We run a medium sized trading system (20 microservices) in Deno for about a year now. There have been a few runtime quirks but they have currently all been ironed out. I love the approach that Deno takes with respect to permissions which allows you to strictly specify which urls your program can access, which files/directories can be read/written, etc.

Onavo• 3 years ago

How are JS's scientific computing and stats libraries?

davnicwil2• 3 years ago

You are most likely aware but just to point out, Node now also has a version of the permissions features [0] (not sure on parity but it was obviously deno inspired) behind an experimental flag!

[0] https://nodejs.org/api/permissions.html

lytedev4• 3 years ago

We have also run it in production for about a year, but it's a tiny metrics collector and doesn't do anything fancy at all. But writing and deploying it end to end was a fantastic and quick experience.

qbasic_forever4• 3 years ago

It's still just V8 under the hood so IMHO it's not nearly as risky as if someone just wrote their own bespoke JS interpretor. And everything around V8 is in rust so there's less chance of catastrophic footguns and crashes (still non-zero, but way more trustworthy than a new C/C++ project).

IMHO the biggest risks would be misunderstanding of capabilities/configuration particularly around its stricter sandboxing, i.e. forgetting it won't let you access file system or network by default and your testing failing to capture some dependency there.

msoad• 3 years ago

With all of this Node compatibility work it should be able to run Next.je at this point. I wonder what fails when one tries to do that?

bartlomieju3• 3 years ago

Bartek from the Deno team here. We're currently missing polyfills for IPC module to be able to use `next dev` command.

borplk• 3 years ago

Can anyone comment on the experience with the feature of producing a single binary? Is it really a standalone binary with all the NPM libraries and everything without needing anything else from the host machine? For example can I ship a self-contained server with it that carries its own html/css/js?

mindbyte• 3 years ago

Yes, until the html/css/js part. There is a tool that puts all your files into an js object and provides your files like a virtual file system. Obviously doesn't go well with bigger files. I wish there was a way to use PE's / ELF's existing ways to embed files, especially for memory usage reasons.

Alifatisk• 3 years ago

The self contained executable & the strict permissions is what catches my eye the most!

Love the direction Deno is headed.

swyx• 3 years ago

what tool is that?

DrinkWater• 3 years ago

Producing an SBOM would be a very nice feature to add to this.

jensneuse• 3 years ago

Deno is becoming more and more useful, but at the same time it feels like the project moves further and further away from the initial presentation of ry.

Already__Taken• 3 years ago

one of the main take aways I got from Ryan's deno intro was pragmatism over preferences.

lolinder5• 3 years ago

Are we talking about the same talk? 10 Things I Regret about Node.js [0]?

Goal #2 (after security) was to simplify the module system, and the very first thing he said about that was no node compatibility.

[0] https://www.youtube.com/watch?v=M3BM9TB-8yA

8K832d7tNmiQ• 3 years ago

another perspective is that you can gradually move away your project dependencies into deno while still using node modules.

lolinder5• 3 years ago

In practice that's not going to happen, though. People will add their npm dependencies and move on, and instead of solving JS dependency hell Deno will become a layer of abstraction on top of it.

A lot of us were hoping Deno would do the Gopher thing and force a complete reset. Yes, that means less/slower adoption, but it means that when you pick up a Deno library you know you're not getting all of npm with it. The further we move along the less likely it seems that any Deno project will be able to be npm-free.

toastercat8• 3 years ago

Agree; I preferred Deno as the small-ish, Web API-compatible, focused JS/TS runtime that wasn't Node compatible. I personally feel all this NPM-compatiblity is a big waste of time.

That being said, I still like Deno.

lytedev4• 3 years ago

On the other hand, at $DAYJOB, being able to say that Deno has access to everything node can do goes a long way. Not having to reinvent the wheels is definitely nice!

qbasic_forever4• 3 years ago

If you don't use the node compatibility do you even notice or care one bit about it? It doesn't hurt a pure deno project at all.

brundolf4• 3 years ago

It's become clear that it's a hard requirement for wide adoption, especially with the new competition from bun. Personal anecdote: I tried to pitch Deno last year at my job, and as soon as I mentioned that it can't use the NPM ecosystem they went "ahh..." and the conversation basically stopped.

So I don't blame the team for being practical. You can still make things better without a clean break

guykdm• 3 years ago

I'm using deno in production and npm compat is, for me, a must.

MuffinFlavored• 3 years ago

I personally feel all this NPM-compatiblity is a big waste of time.

You feel like being compatible with one of (if not the) biggest package management ecosystems for any programming language is a big waste of time?

rnmkr• 3 years ago

No. Deno would've been widely adopted if they were compatible with Node from the beginning.

rubenfiszel• 3 years ago

For deno to grow, it needs to be used in production systems. Deno seems to be betting most of it business in serverless/edge deployment (deno deploy, supabase functions, netlify functions). We also support it for self-hosted infra/internal tools production use-case at windmill.dev. The #1 feedback that we get is that people are frustrated that they have this one script or library they cannot use and that otherwise work with node. Deno is a marvelous piece of engineering that require a team of very qualified engineers, those need to get paid, so some tradeoffs need to be made.

veidr• 3 years ago

Maybe, but as an(other) aficionado of Deno for smallish projects where Node is irrelevant, I don't feel like these panders to the mainstream hurt anything.

To the contrary, they make every conversation about using Deno easier, even where we don't and won't use Node (including NPM packages).

I mean sure, they consume some of their resources that might in some ideal (to me) world be spent on something more relevant (to me), but in this world it seems like engineering resources well spent. ¯\_(ಠ_ಠ)_/¯

benatkin• 3 years ago

I disagree. If it had become powerful enough for them to support node/npm sooner they would have supported it sooner. Pure Deno stuff like fresh is still packaged in a Golang-like way.

BraverHeart• 3 years ago

Isn't one of the main selling points of Deno is the new package management system, wouldn't supporting NPM effectively nullify the benefits?

Will there be a strategy to avoid NPM ultimately becoming the defacto package manager for Deno

throwaway2990• 3 years ago

Sure. But no one wants to use deno cos there’s no packages. And so there’s no benefits over npm. No one wants to link to random GitHub files.

lytedev4• 3 years ago

I like Deno. The benefits to me are largely around developer experience and tooling. I much prefer Deno's dependency management solution to Node's.

Additionally, lots of packages have made their codebase more runtime agnostic as a result of Deno existing, so there definitely are Deno packages out there. It just depends onw hat you're building!

taink• 3 years ago

Keep in mind there is no complete feature parity with NPM. This only allows you to use packages not present in Deno's ecosystem, but it does not guarantee it will work flawlessly (and in practice it can be a pain to use some packages).

The best way to use Deno and take advantage of its benefits is to use Deno's packages. Allowing NPM packages is a good strategic move because on top of already being quite different from Node, there are not many packages, but it does not take away from how well it will work with Deno-native packages.

azangru• 3 years ago

I wonder if deno will ever converge with node the way io.js did.

hnbad• 3 years ago

There are apparently plans to add a deno-style permission system to Node (I think there is experimental support behind a flag in one of the recent builds) but I don't think it will become the default the way deno does it, at least not in the foreseeable future.

davnicwil2• 3 years ago

I put this in another comment also but yeah, the permissions feature is documented here https://nodejs.org/api/permissions.html

It definitely seems that Node is surfing in deno's wake here and taking heavy inspiration from some of the more successful features.

I guess remains to be seen if this will follow in something like the Java / Scala / Kotlin model or if it'll lead to more of a merge a la io.js - I tend to think that a merge fits better since we're dealing with runtimes and not separate languages, but I think the former model could work too.

Either way, great thing for the ecosystem!

vmfunction• 3 years ago

unless node convert to Rust, the future is Deno or rust based approach. The main reason to NOT use node is the who C backend.

frou_dh• 3 years ago

Not really, because it's not a fork and is written in a different language.

dazhbog• 3 years ago

Can it compile native modules like serialport into an executable? or am I dreaming too much?

bartlomieju3• 3 years ago

These modules can be included but currently there's no way to use them - that's because they need to be present on disk to load them as dynamic libraries.

We're debating how to best tackle that. If you have a specific use case in mind I would appreciate opening a feature request in our issue tracker.

tsu_tsu• 3 years ago

Does this mean we can use npm packages with Deno Deploy? Or is that another issue?

bartlomieju3• 3 years ago

It's another issue, but it's close

tiborsaas• 3 years ago

That's super exciting, can't wait to test it.

rafaelturk• 3 years ago

Why I should use Deno?

Kuinox• 3 years ago

It's hype, you need another reason?

StefanWestfal• 3 years ago

For me it is convenience as tooling like fmt, testing, etc. are build in and they try to keep api close to browser api's when possible.

Cthulhu_• 3 years ago

I've no usage experience myself, but, I'd say running (and now packaging or compiling) modern JS or Typescript directly without having to build a pipeline with tools like webpack.

wk_end• 3 years ago

I don't think Deno's gonna help deal with something like Webpack, is it?

Webpack's for building browser bundles, Deno's about running TypeScript server-side, isn't it?

_joel2• 3 years ago

As an admin and not a dev, why would this be beneficial to me, managing a fairly standard app and node/yarn frontend? Sell it to me :)

lytedev4• 3 years ago

For an admin, I'm not sure. The deployment and CI/CD story may be cleaner? The real win to me is the developer experience. Deno comes with everything: test runner, linter, typescript, language server, etc. That's the winner for me.

_joel2• 3 years ago

Cheers, I worded that badly I suppose but you answered the question I meant :)

apatheticonion• 3 years ago

Honestly I don't have an issue with Node's approach to module resolution - especially when combined with a package mangers like pnpm that symlink dependencies.

Multi project workspaces are easy to manage with pnpm and publishing to an npm registry is fine enough.

I thought about git as a package distribution mechanism (like Go) but it adds complexity in how you handle transpilation for releases and I'm not sure how versioning works in the context of multi-package projects/workspaces (how does Go do it?).

I just want to use TypeScript on the back end without a billion years of setup.

Deno 1.34: Deno compile supports NPM packages

Related Stories