Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Support semver via git tags #3511

thlorenz opened this Issue Jun 3, 2013 · 2 comments


None yet
3 participants

thlorenz commented Jun 3, 2013


First off, this may be totally out of scope since it would tie npm to know even more about the inner workings of github which may not be desired. So the main reason I'm adding this issue is to facilitate discussions on how to best solve the problem I'm facing (with or without a change to npm).

The Problem

The problem I'm facing is that I have two modules (both published to npm) which depend on another core module. At this point I published it to npm for the sole reason to get semver support.

For example if I include: valuepack-core: "~0.1.0" in the dependencies of any of the dependent modules, I get core patch updates automatically anytime I update/install the dependents.

However the core module is of no use on its own and I would like to avoid polluting the npm registry with these kind of modules. I tried to to minimize the chance of it showing up in search results by not adding any keywords, but would like to find a better solution.


There are two solutions to this problem, one being more optimal, but requiring a change to npm:

First Solution

Given that I tag my core module with the tags: v0.1.0,0.1.1,v0.2.0, v0.2.1, v0.2.2, I should be able to get the following versions when I install as follows:

npm i user/core#v0.1.0 => v0.1.0 (supported already)
npm i user/core#~v0.1.0 => v0.1.1
npm i user/core#~v0.2.0 => v0.2.2

In order to enable this, npm would have to pull all tags for a certain repo via a call to the github api and then parse them in order to find the best match.

A problem with that is that npm could run over its github api rate limit.
Additionally this could lead to others requesting for support for things like v0.1.x and or >=v0.1.0 which may be a problem as well.

However if at least the ~ feature would be supported it would make it much easier for people to host and properly version core dependencies of their public modules on github.

Second Solution

This solution does not require any changes to npm and I include it here to show that other options do exist.

Assuming that going through all dependencies and updating the github tag is not desirable, we could have them depend on the core module like user/core#v0.1.x.

Then we create tag v0.1.x on the core repository. This tag will have to be manually moved to the latest tag that satisfies 0.1.x.
For example when creating a new tag v0.1.2 we move v0.1.x, which was pointing at the same commit as tag v0.1.1 to now point to the same commit that v0.1.2 is pointing at.

The disadvantage compared to the first solution is that we'd have to remember to move this tag every time we apply a patch.


domenic commented Jun 3, 2013

Dupe of #3014, #3328, #3347, and #3442. @isaacs doesn't want to crawl git tags.

@domenic domenic closed this Jun 3, 2013


luk- commented Jun 3, 2013


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment