Deno - Keeping NPM away

Deno has taken the developer community by, if not storm, some great interest indeed. Those who understand how Deno is different from Node are wondering about the changes, and thinking if they were a good move, and most others, who don't have an idea about how it's different, are busy predicting the death of Node.

I just finished creating a REST API with Deno, just out of interest, to see how it was actually different. Boy, did it give me a lot of pain!

What do we do when we want to run a Node server?

node filename.js

and we're done.

I tried the same with Deno :

deno run filename.ts

Lo and behold. A particularly nasty piece of error spoiled my otherwise brilliant going day. It didn't have the permissions necessary to run it. Really? JavaScript? Permissions?

And only when I added the flag

deno run --allow-net filename.ts

did Mr Deno finally agree to run my server.

And this is only one permission. If my server were trying to access other requirements like the file system, separate flags for all. And given the large population of noobs that enter into dev, we have no other choice but to first run it the wrong way, find out what permission is missing, and then give it. Hell lot of work!

We, developers are known for laziness. Damn, man, the entire quadrillion dollar software industry works because we are too lazy to do stuff manually. Why then, did one of the most brilliant software developers of modern day, Ryan Dahl (Creator of Node AND Deno), choose to incorporate this particularly irritating bit of access control flags?

Another major change that Deno has, is the eradication of use of the quite-infamous, humongous node_modules folder. For the uninitiated, any JS Framework based application uses npm packages to add functionality. Talk react-router in React, one of the most popular. Many of us must have come across something like

npm install --save whatever-the-name

The node_modules folder stores the details of the packages we have installed, such as the version, compatibility, dependencies and others, in the node_modules folder. Also, do note that NPM is community driven. That means that anyone can contribute to it. While the community keeps a strict watch, there are chances of things going wrong, aka someone putting up a package that could misbehave. Also, notice the word dependencies. So curiously innocent. Yet, it has been one of the largest and near-fatal headaches for the NPM community. Why?

Dependencies are packages that the installed packages NEED to run. Meaning, let's say you need react-router. When you do

npm install --save react-router

it'll not only add the react-router package, it'll also automatically add all its dependencies.

Below is the official NPM page for react-router. If you go to the dependencies tab, you'll see there are some 10 dependencies. When you install the package, these dependencies are also installed automatically.

So what's wrong? Cmon, you can't have a computer without a keyboard, can you? This works alright if the world works ideally. Remember Adam and Eve? The world stopped behaving ideally since then.

What if, there is a dependency for an NPM package, that gets removed, or gets corrupted? You might call me far sighted, but that's what happened in the case of left-pad, full story below.

left-pad, due to some copyright issues, had to be taken down. But what was not realized, was that this package was a dependency for a thousand other, much more popular NPM packages. And when left-pad went, boom! See the trouble of dependencies now?

That's not quite it!

Let's come back to the topic of security that we'd discussed. NPM packages are brimming with attitude. Permissions such as access to file system, network resources are implicitly given, and that means that the package, and by implication, all its dependencies can go about using the net and the file system as if they owned it.

You already have the intuition. When machines go awry, they don't go about posting pictures on Instagram. They hit where it hurts. In the case of another NPM package by the name of event-stream, the second story in the excellent medium article linked above, the existing owner of the package passed it on to another user, who added a dependency, which started accessing users' private keys in a Bitcoin application.

The harm that giving implicit rights to NPM packages might cause, wouldn't be much affected when devies like me try and make a simple REST API, but when we're talking scale, that's where things can turn hell-hole in a very short time.

So, that's why, Deno explicitly asks the users to define all the permissions that she/he allows the application to use, and thus, no packages running awry. Also, instead of using NPM, util packages are downloaded from the official Deno website, and then cached for repeated usage.

Several others of Deno's modifications, such as strong typing, are for now, outside the frame of this article, and will be discussed in a future article.

Hope this article gave you one reason to go a little less lazy :P.

Do give it a like.