I've had this happen in the past but since I do it so rarely, I just put ti down to problem with me
But earlier today, @smcgann99 came up with a quick fix for an issue to just cd into .node-red folder and run npm install alexa-remote2 to update it to the latest version (i.e from 6.2.2 to 7.0.4)
This didn't work for me and for at least one other person
I ended up running npm remove alexa-remote2 and then npm install alexa-remote2 and then it updated
FYI When I ran the install command initially (tried a few times BTW) it didn't give any error message but at the same time - it didn't say it had updated anything either)
Any ideas on what the reason could be for this?
Like I say, I've seen this happen a few times over the years I've been playing around with npm but I've never persuded why this happens before
If you need a specific version, such as the latest, you should really do npm install alexa-remote2@latest.
The reason you probably got the result you did was that the package had changed major version. If you check the package.json file in that folder, you will see the version specs for each direct dependency (if it was a deeper dependency, you can get npm to show you which package has the direct dependency and you can look at its package.json).
Doing a npm outdated can also be useful as it will tell you not only what the latest version is but also what version your current package.json will update to.
You will see, for example, that @types/node has a latest version of 20.12.7 but my package.json says that I only should be using 18.* so if I did an npm update, I would automatically get 18.19.31 but if I did npm install @types/node@latest, I would get the v20 package. For eslint, I absolutely DO NOT want the v9 version because it has completely changed its config and wouldn't work. Similarly, I can't use the latest execa version because it is ESM only and so won't work with Node-RED at all - thankfully, I've now eliminated that from the uibuilder dependencies (other than 1 use when developing, not for running).
I also do appreciate your clear answers, with examples -- thanks Julian.
Related to this, I have had some issues with npm update vs. npm install, especially when building a clone of someone else's repo (e.g. uibuilder ;*). Usually I just want to run a local version without changes, but sometimes the package-lock.json is changed so I have to delete or restore it before pulling a newer version of that branch...
Like Simon says, I usually just chalk it up to my ignorance, but perhaps you can suggest a better workflow?
I don't understand what you mean by that. If package-lock is present that that tells npm exactly which versions of packages to install when you npm install. If it is not present then it will install the latest versions of packages that are consistent with package.json. I am not sure what npm install does if package-lock does not exist, but the package is already installed, but is not the latest version allowed by package.json.
If you've cloned a node's repo locally and want to run with it, it is worth remembering that you might install the dependencies in one of two different ways.
When I work on UIBUILDER for example, I install the dependencies locally to the package folder because that also updates the package.json and the lock file as needed which makes it easy for pushing back to GitHub and eventually to the npm catalogue.
Or you can install it as normal to Node-RED and the dependencies go into the userDir as normal. Thanks to how npm works, both approaches are valid.
As for the package-lock.json, if in doubt - delete it. It is only useful if you want to deploy a defined set of dependencies. Indeed, I've often thought that I should probably exclude it from the repo, I suspect for our use, it causes more issues than it solves. In theory, the scopes defined in package.json should be more than enough - it is only if dependency authors haven't done a good job with managing their packages that the lock file is really useful.
In this case I'm likely using npm update instead of install, so it pulls newer versions and updates the package-lock.json file -- which, if it's checked in to the repo now shows local changes to the code.
So either the repo should not include the lock file, or I should only use npm update when I'm looking to commit a newer version of the code back to the branch... I think...
You know, I think I will exclude the lock file from uibuilder v7 (next release) onwards as I can't see that it helps anyone. I've even tripped over it a couple of times myself.
