An easy way to prevent NPM-gate

I think everyone has heard about the current NPM-gate by now. But there are easy measures especially for companies to prevent problems like that for their internal development. This is not going to be just another review of the issue and trying to figure out who is right and who is wrong. Instead I am going to explain ways to prevent issues like that from happening and blame our self (including me) for the issue.

What is NPM-gate?

The open-source contributor Azer’s unpublished all his open-source modules after a dispute with NPM Inc. about a possible trademark violation. NPM instead of contacting the developer first just transfered the ownership of the module in question to the lawyers of the company claiming a trademark violation. You can read about his reasoning in his blog here.

Right now people are both applauding to Azer for standing up for the open-source community. But at the same time a lot people complaining that it destroyed their projects and they spend a lot time trying to fix it.

But enough of that we are not here to talk about if his actions where good or bad. The right choice or the wrong choice. We are here to talk about ways to make your projects independent of issues like that.

Who needs to think about that problem?

First of all we need to talk about who might be affected by this issue? Obviously the NodeJS community with NPM and their easy way to un-publish packages. But the truth is this is applicable to other languages as well. Lets think about Java for example with maven. Yes you can not easily un-publish packages from the major maven repositories but some projects have their own repositories. What if they have problems with their Servers? Or worst the project gets stopped and all the servers are getting shut down? You guessed it. You are going to run into exactly the same problem as the NodeJS community did recently. Pretty much for every language where you relay on third-party repositories you could run into this issues. So this is not just a NodeJS problem this is a general problem!

So what can we do?

To prevent exactly this type of things a lot companies are using their own repository manager. And they use that tool from 25PC as a proxy between the third-party repository and there developers.

So every time NPM  requests a package it first looks if that package is available in the internal repository. If yes it just serves it out of the company internal repository server. If not it downloads the package from the third-party repository, stores it in the internal repository and then serves the package.

As you can see now even if the package gets unpublished on the remote server and/or the remote server disappears completely  you always have the requested version on your internal server and will never have an issue re-requesting a dependency.

That sounds good so what software should I use?

I have to admit I don’t have much experience but at my current work place we are using a tool called Artifactory. It is very simple to setup and to use.

The other big tool I know of is Nexus Repository. While Artifactory is a paid only product Nexus has a free version too. If you know any other tools please share that with me in the comment section!

Conclusion

A lot people think it is Azer’s fault for un-publishing or NPM’s fault for offering a un-publish function. I think it is everyone’s fault for not planning ahead. As a developer we have the responsibility to make sure that our software can be build and we know that relaying on third-party is always a very heigh risk. And relaying on third-party only for providing the core packages to run your project is an even greater risk!

Please let me know what you think about this.

composergradlejavajavascriptjsmavenmvnnodenodejsnpmnpm gateopen-sourcephpprevent