Golang and node. js Package Management Comparison

This is a creation in Article, where the information may have evolved or changed.

Golang and node. JS are two of the most modern languages, often comparing each other when using both. To the grammatical point, the individual still likes Golang's simplicity and innovation most. and node. JS is most satisfying to me is npm. But here's a big deal about the difference between the two package management solutions for dependency processing .

Let's talk about Golang first. Golang's approach to dependency is to make you unaware of the dependencies that are remote or local to the repository. Everything is done through go get . As long as inside the source is

import "github.com/username/projectname"

At go get the time the tool automatically helps you to download the dependent source package. This looks very simple and easy to operate, but it brings me a lot of trouble.

For example, when we need to rely on the project PA today, so write in the source code

import "code.google.com/uA/pA"

But one day you find code.google.com it hard to get a wall and turn over the wall, and you want to use github.com the mirrored warehouse on it. You will need to modify the source code that contains this sentence import . That is, for Golang, warehouse dependencies are coupled with source code . Or, you Fork the project on GitHub,

From github.com/uA/pA Fork into github.com/uB/pA .

And the project's source code inside the existence import "github.com/uA/pA/sub1/" of such a dependency on the Project subdirectory package statement. And when you Fork, you go build 'll get an error saying you can't find github.com/uA/pA/sub1 the bag. This question is not a new problem, such as in C/C++ , #include "xxx" when, the path of xxx should be write relative path . You can't write an absolute path , because when you write an absolute path, for example, the #include "/home/yanyiwu/code/xxx" source loses its portability. Of course there are ready-made solutions to this problem, but this solution is not the perfect solution.

Please see using-forked-package-import-in-go for details.

And for NPM, it's a lot easier. Because NPM's package management strategy is centralized management, when you use npm publish a new package to publish, your code is uploaded to the top of the npmjs.org centralized management. So when you use npm install the installation of a new package, your code is downloaded from the npmjs.org download. Of course, this centralized management has a single point of failure, such as npmjs.org hanging off or being a wall is a tragedy? The answer is in the negative. Because NPM also support the designated warehouse download, such as in the Chinese, the industrious and self-reliance of the program staff to build a domestic mirror cnpm, and very good speed. Using mirroring is also very simple, such as this:

npm --registry=http://r.cnpmjs.org install koa

Refer to FASTER-NPM for specific usage.

When it comes to this, you can notice where the difference is. is for dependency management. Node.jsThe package management solution is source- independent . In the Node source code inside is not need to tube this package under which warehouse. Take KOA this project, in the KOA package.json can see:

"dependencies": {    "accepts": "^1.1.0",    "co": "^3.1.0",     …},

The inside relies on accepts this package, in the KOA source code inside directly var acceps = require(‘accepts’); , the source code does not need to know the accepts source of the warehouse is github.com above or gitcafe.com above. Moreover, package.json another benefit of unified management by NPM through files is that dependency is very clear and all dependencies and corresponding versions can be seen. Glance. The benefits of this centralized package management of NPM can also avoid problems caused by the golang of bread management and source code. So personally, NPM's package management solution is really better. Hope that the Golang after the improvement inside can refer to this solution.

In fact, the domestic technical Forum has a climate is not very good, that is, when publishing a number of different language analysis and comparison, will inevitably cause a variety of language powder hostility. It's better than saying that Golang's package management solution is really inferior to Node's npm. will be Golang powder think I was dedicated to criticize the stadium. In fact, I am also golang powder, so I really have no words for this hostility.