@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
