Things which every developer should know when starting with modern front-end development

Ben White on Unsplash

Disclaimer: This article is a high level overview of how package management and the associated licensing issues work. It is meant to make new javascript developers aware of the concerns which can arise for their project/client/organisation and is not meant to discourage the spirit.

The Javascript landscape has significantly changed over the years. It, now, offers developers many tools to easily manage the complexity on the client end of the application. If you are a developer who has written some non-trivial code in Javascript before when jQuery was not the standard for DOM manipulation you know we have come a long way. I still remember my first ⭐️ moment with AngularJS which made two way data binding so simple. However, although we could go on about how every new front-end library/framework has made our life simple, this article would quickly loose its focus.

Javascript community pushing the boundaries 💥

Why do we need these frameworks/libraries though ?

Javascript is an implementation of the ECMAScript specification. Who is supporting the implementing of these new and upcoming specs? Our very own favourite browsers! Each browser adopts a javascript engine which is responsible for executing the javascript code which we write. Since we/our users are spoiled for choice when it comes to browsers this leaves us with implementation differences of ECMAScript specification. If browsers with their respective javascript engines were consistent with their approach and were keeping up with the latest developments made by TC39 then honestly, for most of the things we wouldn’t need these frameworks and libraries. But lets be realistic!

This is so not true

Package Managers for javascript packages

npm & yarn are the popular package managers for javascript libraries. They have made life really simple in terms of installing, shipping front-end apps e.g. if you need to install a library like vue all you need to do is

<package-manager> add/install vue

and that’s it! It downloads everything it needs to run and you are good to go. Based on the environment (dev/prod/test) in which the app needs to run, you can configure which packages you need for your app to run in that specific environment.

What happens internally when we install packages ?

Every engineer working with npm or any other package manager should know the answer to the above question. A detailed answer can be found here else if you are feeling lazy and just want to know the basics then keep on reading. Every new package brings with itself other packages which are required for it to run smoothly and those other packages install even more packages for them and before you know it your project has a set of packages about which you have no clue. Lets say if you install a package Bfor your app Athen you have a direct dependency on this package and if it needs a package Cthen you have a transitive dependency on package C and so on.

Why should we bother about transitive dependencies ?

In any application, the graph of dependencies is complex and is not visually appealing also 😛 when compared to the graph below. Depending on what packages you are using for your project the graph can have many more levels and many more nodes to it. Basically, longer and wider.

A very simple dependency graph

Let’s imagine a slightly more practical scenario where the graph looks something like below for your project. As you can see that there are multiple paths which lead to packageX Consider B_1_ & B_2_ as two different packages and the same for C_1_ and C_2_ since the numbers 1 & 2 are not to be confused with the versions of packages B & C.

A -> B_2 ->_ C_1 ->_ X & A -> B_1 ->_ C_2 ->_ X

non-trivial dependency graph

X since it’s marked in red represents something which can cause problems for your project in some ways. Lets have a look at the two popular scenarios where things can go wrong due to package X

Security

We don’t really know what the transitive package(s) are actually doing under the hood (I am assuming you already know what the direct dependencies are doing — you should! 👨‍🏫) it might happen that you end up installing a package which tracks sensitive user data on forms, like usernames, passwords or any other personal information else if you are running javascript on the server then Prototype Pollution and ReDOS is something you should keep your hands away from. I am not a security expert, but if you think from a perspective of a cracker there can be so many other ways where a malicious package can cause security issues.

A motorist by-passing police security check 👮

Legal

Packages such as vue, jquery etc. have a MIT license, which can be paraphrased as saying,

It lets people do anything they want with your code as long as they provide attribution back to you and don’t hold you liable

pdf.js uses Apache License 2.0 which quotes

Similar to the MIT License, but also provides an express grant of patent rights from contributors to users

Both the above licenses seem fine and seem to pose no threats no matter what type of use you put them to, even commercial. No matter how restrictive a license is for a third party package it is not an issue until it is distributed to the public (unless the package license terms state explicitly that its illegal to use privately also) and it’s also ok to distribute the package to employees who are part of the same organisation.

License check fail ❌

Now you might think that since your software/service is distributed over a network for a SaaS (Software as a Service) based product of yours and is not present on a user’s machine that it’s ok to use any third party package — but licenses like GNU AGPLv3 also considers network usage as a distribution of the software.

How can the above security and legal issues be prevented ?

A bearded person who decides to quit 😫

Now that we know what the problems are, a reasonable solution, from the top of my head is to come up with a way where by we can look at each package which is used (directly/indirectly) by my project starting from the package.json file (for npm). This is something which is called a deep scan of dependencies. Your deep scan should be able to look at each package and make a decision whether it is safe to use or not from both security and legal perspectives. This whole process has three parts to it :

1. To be able to scan efficiently and properly all the dependencies in your project.
2. To be able to make a decision on whether it’s safe to use a package from security and legal point of view.
3. Doing 1 & 2 repeatedly

There are some open source and proprietary APIs (RetireJS, NSP, Snyk, fossa) which can help with some or all of the parts of the process, you just need to figure out what is best for your case. There can be scenarios where your checks discover a vulnerability but sometimes its ok to avoid them e.g. if you are not running javascript on the server then ReDOS vulnerability can be considered non-dangerous.

To summarise, the concept of npm and package managers is awesome but always keep your eyes open for what your dependencies are bringing with them for you. Cheers!

Happy Coding 😺

Some sources which can be further useful

• Understanding the dependency model
• Choosing a license for your project
• Vulnerabilities tagged by risk
• Great article by Vova Bilonenko on why should we care about licenses