January | 2018 | I learned it. I share it.

Well, maybe not, but your imports may indicate, how maintainable is your code.

Have you ever written something like this:

import { SomeClass } from 'somelib';
...
const s = new SomeClass();

Or this:

import * as someFunc from 'somelib';
...
const s = someFunc();

Looks familiar, right? I’ve written a lot of lines like these, mainly because the README in every library, package recommends them. But there are (at least) two problems with this code why I am trying to avoid them.

Dependency management

If you unscrupulously follow this pattern, you will write the same line of code hundred (or more) times within a single application. Why? Because we love copy-paste. Easy, convenient, and it works, right?

However in this way it will be very difficult to determine what your app exactly needs, what it depends on, what are its dependencies. What one can easily see from your code (only after using the “Find in All Files” feature of your favorite editor), is that your code references to an external package in countless places, so it needs that package, your app depends on it.

But reality is different: your application logic does not need a package, but a functionality, a logic, which happens to be implemented in a third party package. But it’s not what your code shows at the first sight.

Here’s a more specific example with the popular lodash package (*):

var _ = require('lodash');

This package provides a number of utility functions, and it is pretty much impossible, that your app needs all of them. How can you find out what exactly you are using? Search all your files for “_”.

But why is that interesting?

For example, because you may want to replace the referenced package with something else. In the open source world, packages come and go, today this was the best, tomorrow that will be the one. Because the old package contains a bug, that will never be fixed, or because only the new package is compatible with the latest Node version that other parts of your app requires. Or simply because you want to keep your codebase fresh, and you want to use only dependencies with active community.

You can be sure that you will not find another library or package, that is API-compatible with the old one. You need one that is compatible on functionality level, which you can only find out if you know exactly what functionality are you referring to.

When you have that, you just have to change the references in as few places as possible in your code.

This leads to the solution: make sure, that you reference third party packages only once in your code, so wrap them into classes that publish only the functionalities your app depends on. This method can also make your code more readable, for example, instead of "sha256()", you can find a much better function name, right?

This method works for me very well for a long time, though I have to note I don’t follow it fanatically, because it will be too much overhead for framework level libs (e.g. Angular).

Testability

If your class uses “import” to refer to another one, unit testing that class will be a nightmare, because you will have to hack the file loader logic to mock the class (e.g. Mocking Request-Promise).

The solution is not new: DI. Not only does it make testing easier, but typically you just have to take a look at the constructor, and you will see on what other classes this one depends on.

For example, in TypeScript, we often import interfaces just to have type description, which can make import rows very verbose, and often you cannot determine at the quick glance which import brings in functionality and which one is there for type information only. DI also helps in this, if we try to use “import” only for type descriptions, and DI for everything else.

Is this something new?

Not at all. Really. Yet these codes continue to live, even if they are hard to maintain. READMEs, tutorials, articles, blogs will always strive for simplicity, you will find examples of them that help you understand the content and get started. Their purpose is not to blindly follow them in a more complex application where maintenance and sustainability is as important as simplicity. When you write such a line next time, think about what you’re really bringing into your codebase. Do you really gain some time with it on the long run?