Update script not updating

ankonaskiff17

@sdetweil First thing I did with the MMM-Jast notification was to look if there was a section in the Readme about updating module but I think it was triggered externally.

On Github the dates are older but there is this at very top, How do I address that?

sdetweil

@ankonaskiff17 so in general, modules update with

cd ~/MagicMirror/modules/module_folder
git pull

and if the module has a package.json, then

npm install

also in the module folder

ankonaskiff17

@sdetweil I found a different module with update instructions and did git pull in MMM-Jast but git pull yielded the following

From https://github.com/jalibu/MMM-Jast
5a5f781..8b771b6 main -> origin/main
* [new tag] v2.6.3 -> v2.6.3
Updating 5a5f781..8b771b6
error: Your local changes to the following files would be overwritten by merge:
package-lock.json
Please commit your changes or stash them before you merge.
Aborting
pi@mirror:~/MagicMirror/modules/MMM-Jast $

sdetweil

@ankonaskiff17 yeh, erase package-lock.json
then git pull, npm install will update that file again

ankonaskiff17

@sdetweil That is standard/typical of how to update a module?

Resolved notification

sdetweil

@ankonaskiff17 yes… no one should ship a package-lock.json as part of their release

this is only used by testing systems to make sure the environment is exact

strawberry 3.141

@sdetweil actually the opposite is true, everyone should ship a lock file with its repository to ensure you will get the exact same dependencies that were tested with and not something newer which can introduce issues.

But if you just run npm install npm will update the lock file. So the effect is like not shipping a lock file at all.

Instead, you should use npm ci if there is a lock file https://docs.npmjs.com/cli/v8/commands/npm-ci. This makes sure that you have exactly the same dependencies no matter if there is a newer version available.

sdetweil

@strawberry-3-141 however. not everyone runs the same platform as used during test, so all the parts change.

strawberry 3.141

@sdetweil the hardware might be different but at least the code and dependencies are the same which increases the chances to reproduce and fix the issue

sdetweil

@strawberry-3-141 but thats not true

on intel I get one version
on arm (32bit) I get a diffferent version
on arm (64bit) I get a different version
on aarch64 i get a different version

especially if there is a binary… and who knows what is buried under there