Clever Library Wrapping

A Small Tip That Will Save You a Lot of Time, Bugs, and Rage.

Let’s say you work on a huge project with many people and it is important to you that a library will be called from a wrapper you created around it or at least they know about the existence of such a wrapper.

For example, let’s take a logging library like winston.

After it’s initialization:

Any developer can just import it and use it as they wish:

But what if you have a fancy wrapper around it that reports errors to a remote server, and formats and standardizes the logs?

You wouldn’t want developers to use it directly but to use your module instead. And they will use it directly. In some point, they will. Trust me.

A similar issue can arise if you add a library that provides you with some kind of component. After styling and wrapping it, developers can technically still import both the styled component and the raw one.

This scenario is actually pretty common because when developers will look in “package.json” they will only see the raw library.

This means you are in danger of someone styling and wrapping a library again instead of using a ready wrapper.

In short, my answer is to use no-restricted-imports linter rule or an equivalent rule in other linters to notify the user that the library is restricted:

Being restricted by the linter will lead the user to look at the linter configuration where an explanation about the restriction will be given:

To still use these imports a linter suppression comment should be added:

Happy programming and let me know if you have other solutions or tips regarding this issue.