npm update: pull from github repo not taking latest commit

user_511302 0
Viewed 2612

One of the packages in a project is based on an internal npm repository.

{
  "dependencies": {
    "my-library": "git+ssh://<gitrepo>#dist"
  }
}

Where dist is the branch to clone from. This "works" as in it install the correct version. However whenever an update happens to this branch I cannot update using npm? - I tried npm update My-Library but this just downloads the old commit, it doesn't shift to a newer commit in the same branch.

The only "solution" I found is to manually delete the library from the node_modules folder as well as delete the library entry in package-lock.json (or update the reference there to the correct commit).

What is the correct way to make a library follow the latest version of another git repository?

EDIT: if this is just a definitive "not supported" that's also enough of an answer for me.

npm node.js git
2 Answers

From my understanding and experiment, the problem seems related to how package-lock.json work. I setup a lib with one dependency set to

"fn-with-hooks": "git+ssh://git@github.com/hackape/fn-with-hooks.git#master"

and initial npm install would generate a package-lock.json that contains

"fn-with-hooks": {
  "version": "git+ssh://git@github.com/hackape/fn-with-hooks.git#fa1e21a8ea2fd2b0b7ec5897b954266791b56ac4",
  "from": "git+ssh://git@github.com/hackape/fn-with-hooks.git#master"
},

As you can see, the version field is locked to a specific commit hash, and subsequential call to npm install will not change this version field, thus prevents "tracking" the branch up to latest commit. It's just how lockfile is supposed work.

Remove package-lock.json, (no need to remove node_module/lib) then npm install can resolve this problem.

My immediate thought is try to exclude this specific lib from package-lock.json. But the npm lockfile is a whole-sale solution and provide no such fine-grain control.

So the only option down this path is to disable package-lock.json.

If you still intent to use package-lock.json, one workaround is to mannually run npm update lib-name command to force update that lib to latest version. This will also update the version field in lockfile accordingly.

update

I’m not sure why npm update doesn’t work on your side. It works on mine. Maybe you want to double check if it’s indeed the fact, or your misunderstanding. Although I seriously doubt it is, it could also be npm version difference. I’m using v12.14.

I have another workaround, which I tried and it worked. You don’t have to delete the whole package-lock.jsonfile, you can rewrite it to just exclude the record of that git-base lib. This way npm lacks the lockdown information, so it’s force to re-fetch your lib. The other lib records in lockfile remain untouched, so limits the scope of influence.

user_36173800

The behavior you describe is not the behavior I'm seeing (although see last paragraph for a possibility of what might be happening). I created a module that prints a console.log() and pushed it to a git repository branch. My package.json looks like this:

{
  "name": "temp",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "MIT",
  "dependencies": {
    "slug": "git+ssh://git@github.com/trott/slug.git#temp"
  }
}

My index.js:

require('slug');

I ran npm install and node index.js and saw the expected message.

I then updated the message, committed and pushed to the branch. I ran npm update and got the new message.

I updated the message a second time, committed and pushed to the branch again. This time, I ran npm update slug and it still updated the package.

My npm version is 6.14.8.

The one thing I did that caused it not to update is if I used different case, which I notice you do above. Your package.json entry says my-library but your command is npm update My-Library. Different capitalization. I did npm update Slug and it didn't update the module. Could that be the source of your trouble? If not, what might you be doing differently than I did above? If nothing comes to mind, perhaps you can try what I describe above and see where it breaks down for you? (Or is your test case already that simplified?)

user_4366410
Related