Well....
It has now decided to update to 2.1.3
Seems - and I am only calling it as I see it - that somehow sudo systemctl restart nodered doesen't work.
(shurg)
Thought.
Machine has been rebooted.
This is the state as the web shows it for what needs updating.
node-red-contrib-cpu
So, I shall do the update from the CLI and report back.
(changed update to install)
npm install node-red-contrib-cpu@0.0.4
(I'll wait for your go/no go if you don't want to be dragged through it.)
Just it would be interesting to see what happens with an update then a NR restart.
Well, I am nearly asleep, but...
I did another node with the @x.x.x and it worked.
Going to bed.
20 hours awake.
Need sleep.
Nick, thanks
TotallyInfo, thanks.
Everyone else: thanks.
I would have expected to find a flag on npm update and/or install to tell it to ignore the spec in package.json and update to the latest version but there does not seem to be one.
Possibly the easiest way to update to the latest is therefore to uninstall it and then install it again.
npm uninstall some_node
npm install some_node
Another possibility is to edit package.json with a basic text editor and remove all references to the nodes that I want to update, then npm install will install the latest version.
@Trying_to_learn just a word of caution. When you upgrade to a later major version (which is what you are trying to do), then you may find the node no longer works, as the reason for incrementing the major version (the first number) is to indicate that there may be changes to the node which means that it no longer works the way it used to. Breaking changes they are called. There may be extra config information you need to setup for example, or it may need a later version of node.js. This is the reason that it is quite hard to do what you are trying to do. My approach is that once I have something working I don't regularly upgrade to a new major version unless a bug is fixed that I need fixed, or some new feature is added that I need. Then every so often when I have a bit of time I may upgrade everything in the knowledge that I then have to test everything and make sure it still works.
1 Like
@Colin I don't see anything in the npm outdated output that shows a major version change. What am I missing?
Personally I find npm install module@version the most deterministic (and reliable) way to install a module at a desired version.
You can use npm i module_name@latest to fetch the latest version without having to know the exact number.
You can then use npm ls --depth=0 to list the installed packages at the top level only so you can see their version numbers easily. (without having to work through the massive tree)
It seems you are right, I didn't look carefully enough. Sorry @Trying_to_learn it seems you are not trying to do what I suggested. That presumably means that package.json specifies something other than the default which is (I believe) ^x.y.z which means that the minimum acceptable is x.y.z but anything up from that but keeping the first digit unchanged is also acceptable.
You are right that using npm install module@version is the way to install a specific version, but I imagine (I have not checked) that the result will be the package.json will specify exactly that version must be installed so you can't update bug fixes or non-breaking changes just using npm update.
It would help if you checked before speculating - there's enough misinformation and confusion in this thread.
The default behaviour is the same if you provide a version or not.
True, I consider myself suitably chastised. I couldn't immediately see how to easily test it, but actually all I had to do was to remove a node then re-install specifying that version, and indeed as you say, so, for example
npm install node-red-contrib-bigtimer@1.9.2
installs 1.9.2, but in package.json it has put
"node-red-contrib-bigtimer": "^1.9.2"
which means that npm update will update to the latest 1.x.x
I find that a bit odd when a specific version has been asked for. But I find quite a lot about npm a bit odd.
Fantastic, that is what we needed to know. I have checked and that takes no notice of what is currently in package.json so that is exactly what I was looking for. I had expected it to be a switch.
So @Trying_to_learn the solution is that for each of the packages you want to update to the latest version you can use that command to do it.
Here is a good background read on semantic versioning and how npm uses it (or not) - https://nodesource.com/blog/semver-tilde-and-caret
The subtle extra info that most folk don't realise is the section around Caret: Major Zero section. Namely that anything under Major version 1 (I.E. nearly all these nodes we are talking about) - then ^ actually behaves the same as ~ and will only update at the patch level - not the minor level. Net is npm update will only update patch levels for these nodes - and then only if set to do so in the package.json.
Net net is to use npm install module_name@version_number as @knolleary suggested or npm i module_name@latest if you are feeling lucky.
1 Like
OK, I know this discussion may have gone on too long, but could someone explain how it started out using npm to update nodes instead of the Manage palette menu item? When is this likely to be necessary? It seems that NR picks up the latest version of nodes (ignoring the wanted versions), at least in the case of all the nodes I'm using. I've never actually resorted to npm for this. Did I miss something in the conversation?
npm is the tool used under the skin by manage palette, npm on the command line was the only way to manage nodes before manage palette came along.
Node-RED is built using Node.JS which typically uses npm to manage additional libraries and modules which is why Node-RED also uses it.
It isn't necessary for the most part. This thread started because the OP was installing a node that required a binary to be compiled on his device and it was taking so long that the manage palette interface timed out (I think). So he went to the command line to install instead.
The thread went off-target somewhat when we also tried to help him understand more about npm.
No. I said a few times I cannot explain why Andrew had to resort to the command line to update these particular nodes.
The command he ran in the end to fix it (npm install module@version) is exactly the command node-red runs when you use the palette manager to do an upgrade.
1 Like
Thanks for clarifying that for me. One last question since
Does NR pick up MAJOR version changes? Let you install them or give a warning? I don't think I've ever run into that situation.
I don't want to keep this going longer than needed as I agree with Nick: It has kind of gone on a bit.
I'm kind of just out of bed and completed today's tasks to this point in time.
So to go over what I have been told:
(and a bit of the story so if someone new doesn't want to read all the above stuff)
From the web page, I was trying to update a node and it said it was updated.
1 - The list didn't show it as updated - from another thread. (I don't want to go there here/now)
I would restart NR (well, more like reboot the machine) and it would not show the updated version.
2 - To get "around" this problem I would go to the CLI and do this:
cd .node-red
npm install (module name)
sudo reboot
This had the same result.
3 - Now if I have/see such problems again this is the way to do it.
a - cd .node-red
b - npm install (node name)@version number from the palette page
c - sudo systemctl restart nodered
(also while editing)
It is not a good idea to do:
npm update (package) Use the install option.
Yes/No?
Now, just to check other hitches I see:
(and these are more at my end than the people posting.)
npm install (module) is the same as npm i (module) Yes?
npm outdated is a way to get a list of modules needing updating.
From there I see 3 numbers: Current, Wanted and Latest.
It is better to do:
npm install (module)@ Wanted rather than latest, as latest may cause problems.
Problems in if the Latest number is significantly bigger than current.
(From DCeeJay)
npm ls --depth=0 is handy to get a list of installed packages. (Ok, I was calling them modules. Sorry)
DCeeJay,
Sorry, so what is the difference between npm ls --depth=0 and npm outdated other than (now looking at it) the fist will list all where as the second one will only list the old ones.
I'b better stop here, in case I am digging a hole.
P.S.
npm i (package) is that the same as npm i (package)?
I'm guessing it is.
I was mistaken when I made those points, at least for your current situation, sorry for the confusion. If you want to update to the latest version then you can always use
npm install module_name@latest
(yes, npm i is the same as npm install) Only if you want to update but not to the latest do you need to use @version.
Colin,
That's ok.
You are allowed to make mistakes. And given what was happening, mistakes happen.
Indulge me (as you are awake) if this is right.
(I'm starting the roll out now)
_connect to RPI_
cd .node-red
npm outdated
npm install (package) (Given not too big a version change.)
If there is then to the @ option.
When done:
sudo systemctl restart nodered
As I said, if you want to update to the latest one available (as shown by npm outdated or in the node-red palette then use
npm install package@latest
Ok. Thanks.
Am doing that now.
Ten machines to do. Fun fun fun.
