32

I have an git repo and I'm trying to set it as a dependency in my project. Using NPM, my package.json looks like this:

"devDependencies": {
  "grunt": "~0.4.0",
  "grunt-contrib-connect": "~0.2.0",
  "grunt-contrib-watch": "~0.3.1",
  "custom":     "git://github.com/myGitHubRepo/repo.js.git#b7d53a0cfbe496ad89bde6f22324219d098dedb3",
  "grunt-contrib-copy": "~0.4.0"
}

On the first

npm install

It install everything and fetches the repository with no problem. But if I change this commit hash to let's say

"custom":     "git://github.com/myGitHubRepo/repo.js.git#d6da3a0...", // a different one

It doesn't update! Can anyone point me out how could I get this behavior?

I would simply like to share this code and be able to at some point change this version and the npm would automatically update this.

hong4rc
  • 3,999
  • 4
  • 21
  • 40
José Leal
  • 7,989
  • 9
  • 35
  • 54
  • Do you get any errors when trying to `npm install` the 2nd time? Also, does either the `"name"` or `"version"` in the `package.json` change in value between those commits? – Jonathan Lonowski Mar 12 '13 at 17:19
  • Are you updating the version number in the package.json? – Ryan O'Neill Mar 12 '13 at 17:58
  • I don't understand what do you guys mean. The dependency is like "name": "version", correct? So in this case is "custom": "git-hub-url#commit-hash". If I change the "commit-hash" part, it's like it is a new version, no? Or I should declare this dependency name somewhere else? – José Leal Mar 12 '13 at 19:43
  • @JonathanLonowski none. It simple waits a little bit (i have the impression it's looking up in git) and then returns without error. npm update simply doesn't do anything – José Leal Mar 12 '13 at 19:46
  • Actually I just tried changing the version number of the app in the package.json, and after "npm install" it still didn't update the git dependency to the right commit-hash – José Leal Mar 12 '13 at 19:51
  • 1
    @JoséLeal Sorry. I meant the `"name"` and `"version"` within `git://github.com/myGitHubRepo/repo.js.git`. NPM will download and cache the package based on those. If you have 2 commit hashes that have the same `name@version`, then it might not think an update is necessary between them (may be very wrong about that). But, you can reset the cache with `npm cache clear` and maybe try `npm install --verbose` to see everything it's doing. – Jonathan Lonowski Mar 12 '13 at 20:08
  • @JonathanLonowski still didn't work =/ I did the `npm cache clear` and now it seems that it is really going to the git repository. Using `npm install --verbose` I see a `addRemoteGit` with the right URL and commit. But then it still doesn't replace the contents. Here is a gist with the relevant content that I could get (it does println, so tee or > didn't work out) https://gist.github.com/jolealdoneto/5146813 . On this case I tried putting on "#master" as commit-hash, put the behavior is the same with a specific commit-hash. – José Leal Mar 12 '13 at 20:43
  • Ahhhh, do you mean in the package.json within `myGitHubRepo`? I'll try it now. – José Leal Mar 12 '13 at 20:56
  • when using git repos, `npm remove PACKAGE` followed by `npm install` should work. – Pascal Belloncle Mar 13 '13 at 09:49

5 Answers5

16

Ok this is how it is done.

I was also confused.

So i have a private npm module at git@github.com:myModule/MySweetModule.git I have just published the latest tagged version. Unfortunately i cannot figure out how that works, BUT it works off your master. SOOO your master branch can be your integration branch and you have stage branch for building up the next version. Upon version completion, just merge it into master and increment your private repo's version (so your private repo now went from 1.0.0 to 1.0.1). If you call npm install it will update your repo if the master's package.json version is greater than current working repo. It will always take the latest repo.

That seems like it sucks

I agree. So lets do it a better way! If you tags for your private repo releases you can reference them by "custom": "git+ssh://git@github.com:usr/proj.git#TAG_NAME"

So it i have a tag called 0.1.0, then i would have the url in package.json versioned like so. "custom": "git+ssh://git@github.com:usr/proj.git#0.1.0"

I believe that this is the best approach to your answer. But i am not a gitanista

WARNING

If you try to go back a version, it appears it does not work. so from version 0.2.2 to 0.2.1 it will not update your project. Make sure you do npm remove myProj then npm install if you roll back a version.

ThePrimeagen
  • 4,462
  • 4
  • 31
  • 44
  • 2
    Shame there's no easy way to specify a version range, like `~0.2.x` or `>=0.2.0` or something – joneshf Jul 19 '13 at 20:57
  • This is at least what i have found. There could be a way but from documentation there currently is no supported github tag version support. – ThePrimeagen Jul 22 '13 at 14:18
  • @joneshf there is a way now. But its another "npm" like package manager. Its called Component. https://github.com/component/component This supports semver. – ThePrimeagen Mar 25 '14 at 22:19
  • 1
    When I push a new `package.json` to the git repo, `npm install` doesn’t seem to notice. It only seems to check when I change the `#hash` value. E.g., adding or removing `#master` seems to cause it to recheck. So I don’t understand how setting the tag to something like `0.1.0` would be different unless you plan on changing that each time… – binki May 22 '17 at 01:31
  • I believe it should be `"@some/package": "github:some/package^0.1.0"` instead. – kano Aug 12 '19 at 13:11
11

manually updating that specific package did the trick for me.

and to do that automatically i added this postinstall script to my package.json

"scripts": {
 ...
 "postinstall": "npm update custom"
}
Nestoro
  • 787
  • 6
  • 17
  • 1
    Word of caution for this approach: npm appears to be VERY naive in it's update process for a package. For me, it is recompiling ALL dependencies even in devDeps which means things like node-sass and puppeteer cause IMMENSE lag in install times especially if your dep trees get deep with this. – Diniden Aug 08 '22 at 20:31
2

I encountered this question and all the answers had their own set of issues so I had to find a better means.

I have discovered a newer way to prevent this npm issue with package upgrades on install within the docs (this MAY require newer versions of npm):

Ensure you are tagging versions in your repo.

Then you can include your repo using this slightly modified URL:

git+ssh://git@<repo url>.git#semver:<tag/package version>

This behaves MUCH better and has no issues with downgrading or upgrading the version as I have seen thus far.

Diniden
  • 1,005
  • 6
  • 14
  • Looks like this is the way! That `#semver:X.X.X` part makes all the difference. `git+ssh://git@github.com:my-org/my-package.git#v1.0.0"` only installs the correct version if it doesn't exist both in `node_modules` & `package-lock.json`. While `git+ssh://git@github.com:my-org/my-package.git#semver:v1.0.0"` works as expected with `npm install` – Shinebayar G May 12 '23 at 20:31
0

Manually updating the package, as suggested by @Nestoro also worked for me:

npm update
npm install <your package name>
Boris Verkhovskiy
  • 14,854
  • 11
  • 100
  • 103
0

The solution I found is to delete package-lock.json and then execute npm i

JonathanPerry
  • 1