Unable to update modules

[sdetweil]

@KumarTRD said in Unable to update modules:

any way to remove it manually?

yes, the rm command

[KumarTRD]

@sdetweil thanks for the script I’ll save it for later use and it worked thanks!!

[rmcon]

Resurrecting an old thread. Still fairly new to this stuff and trying to learn how to solve problems others have had before…

I’ve got notifications that several modules need to be updated and I’m trying to get them done. Currently attempting to update MMM-Remote-Control using the instructions provided :

cd ~/MagicMirror/modules/MMM-Remote-Control # adapt directory if you are using a different one
git pull
npm install # install (new) dependencies

I am getting the same messages as the OP. I am in the module folder and tried running the rm command and I get this:

~/MagicMirror/modules/MMM-Remote-Control $ rm package-lock.json
rm: cannot remove ‘package-lock.json’: No such file or directory

I thought maybe that meant that I had deleted the package-lock and tried running the update command again, but keep getting the same message.

I tried running the install script again, and when asked if I wanted to update (Y), I ended up with the same problem.

Appreciate any guidance. Running MM v2.30.0 (installed using Sam’s scripts) on RPI 3B+.

[sdetweil]

@rmcon post results of

git status

in the mmm-remote-control
folder

[rmcon]

@sdetweil
~/MagicMirror/modules/MMM-Remote-Control $ git status
On branch master
Your branch is behind ‘origin/master’ by 8 commits, and can be fast-forwarded.
(use “git pull” to update your local branch)

Changes not staged for commit:
(use “git add/rm …” to update what will be committed)
(use “git restore …” to discard changes in working directory)
modified: modules.json
deleted: package-lock.json
modified: package.json

no changes added to commit (use “git add” and/or “git commit -a”)

[sdetweil]

@rmcon ok the quick way

git reset --hard HEAD

then
git pull
Then
npm install

[rmcon]

@sdetweil
That worked! No idea what we just did, but the update went through and MM worked fine after reboot, to include the module,

Sam, you’re a wizard as far as I’m concerned. Thanks for taking the time to assist us less savvy folks.

[sdetweil]

@rmcon thanks, but no wizardry

a little info

we use a source code repository, that keeps track of every file change, add, delete, rename, whatever.

on linux there is no hidden file attribute, like on Windows… but by convention, if a file or folder starts with a dot(.) then it is not shown unless explicitly requested

git is the source code repository we all use (MM and the modules)
it is called a distributed scm (source code mgmt) system, because whenever you have some of a repo, you have ALL of it from its start to now…

you git clone to make a local copy (linked to the source of the clone)

on linux that is stored in the .git folder (notice the .)

it knows about every little change to any of the files… oh
when you see them, that is called the ‘working copy’… may match the repo, might not

so, we asked git, tell me the status of the working copy as compared to the repository (in the .git folder)

and it said some file hadchanged and some file had been deleted.
neither of those files (package.json or package-lock.json) affect the actual running of the module, they are part of the housekeeping, setup, installation…

now, you said you were going to UPDATE cause the module had changed,
so you don’t NEED those files as they exist(or don’t) , cause you are going to PULL a NEW copy of the repo to your system (repo and working copy)

git provides commands to do lots of things,
you can look thru the history of the repo, with git log and git history

an important idea, is a pointer to the top of the last incorporated (committed) changes
that term is called HEAD, the HEAD of the change tree…

so, we asked git, please restore our working copy (and any potential additions (commits) to the repo BACK to the HEAD position
AND reset all the working copy files too…
git reset --hard HEAD
–hard means and working copy
ok, so NOW we have the working copy matching the repo state of the clone you did

now lets ask to refresh the local repo with the repo copy that has changed
that action is PULL the repo to us, and resynch
(it doesn’t like it when the working copy doesn’t match its expectations, so we ‘forced’ it back to HEAD)

now the PULL updates the repo, AND the working copy… phew… and it updated the two files it was unsure about before

but who knows what the impact of the change are (the module author, did we look at any comments he might have made (no… not me!)…)
so, lets just redo the node package managers view of the system
npm install will recheck any locally added libraries (in node_modules folder)
and do any pre/post install tasks defined in the package.json

NOW we are file level up to date with the latest official repo
AND we are runtime up to date