Discaimer

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.

Solutions

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.