Hacker News Reader

Comment by BinaryIdiot | Hacker News Reader

So this reads to me that they're simply not going to update the ability to use GIT. Right now you can point to a repo or specific branch / tag but it doesn't read any of the versioning like bower does, so it can't handle versioning properly. If they updated the use of GIT you could completely eliminate the need for this feature.

That kinda rubs me the wrong way; it feels like they're trying to force this monetization as they've had plenty of us from the community wanting better GIT support for this very reason.

Honestly npm isn't a very complex piece of software, you could even replace it with bower if you want git with versions. I wonder if any competitors are going to spring up who can simply iterate faster. I won't even get started on their login system, ugh.

View on HN

> Right now you can point to a repo or specific branch / tag but it doesn't read any of the versioning like bower does, so it can't handle versioning properly.

You can even point to a specific commit hash. But no, it doesn't read any of the versioning. What if two different branches have the same version number? The publish step is pretty important, because ...

> If they updated the use of GIT you could completely eliminate the need for this feature.

... You'd still miss out on the prepublish hook - one of the major reasons I've looked into using NPM Enterprise.

Sometimes your package needs to do some housekeeping _before_ you publish, and the files generated by that should be distributed -- but not checked into source control.

> You can even point to a specific commit hash. But no, it doesn't read any of the versioning. What if two different branches have the same version number?

The semver mechanism would be based on the tag, so it would not work when pointing to a specific commit hash (and you wouldn't want it to).

> ... You'd still miss out on the prepublish hook - one of the major reasons I've looked into using NPM Enterprise. Sometimes your package needs to do some housekeeping _before_ you publish, and the files generated by that should be distributed -- but not checked into source control.

That's a nice feature and all but not required to have proper git support.

You can easily refer to a version by specifying it via hash

some-user/some-module#1.0.0

Now this is not very robust, as it does not manually incriment semver. That being said a module it not a git repo. There are pre-publish hooks that can be used to execute scripts before publishing. Further, tracking off of git introduces an entirely new set of problems from tracking tar balls. I can see why the team would not be particularly interested in investing time in it.

> Now this is not very robust, as it does not manually incriment semver.

That was the parent's criticism. Other systems do increment semver.

> read any of the versioning like bower does, so it can't handle versioning properly

What would the "proper" behavior be? How would npm know which commit is the one you intended to be the version change? Scan the history of package.json and only grab the commit when the version number changed?

Isn't that entirely the point of using tags?

NPM doesn't use tags to do semver comparisons. To NPM a tag is no different than a branch or a commit hash. This differs from Bower and half dozen other package managers that do semver against tags.

Bower has a backend that is reading the git repo and converting tags into semver versions. They automated NPMs publishing process. Doing this in realtime in the NPM client would be very time consuming.

> Doing this in realtime in the NPM client would be very time consuming.

Nonsense; this is a very quick operation in git. Even in enterprise situations you're probably not going to have a huge amount of private repositories.

Reply on news.ycombinator.com