When I had 1.1.3 installed the following worked...
npm list -g | grep '@types/node'
Now this works...
npm list | grep '@types/node'
│ │ │ ├── @types/node@12.19.0
│ │ │ ├── @types/node@13.13.28
Just asking if this is expectation forward?
If I do a 'npm install' against the package.json... could that have moved Node somehow? I ran the official script to install 1.2.2, then npm install against my existing package.json... which I created from scratch as I populated 1.1.3. Wondering if Node could have moved some how? I just can't see that happening no reference to Node in my package.json.
{
"name": "node-red-project",
"description": "initially created for you by Node-RED 1.2.2 ",
"version": "0.0.1",
"private": true,
"dependencies": {
"i2c-bus": "^5.2.1",
"node-red-contrib-advanced-ping": "^1.2.0",
"node-red-contrib-bme280": "^1.0.0",
"node-red-contrib-cec": "^1.0.2",
"node-red-contrib-counter": "^0.1.6",
"node-red-contrib-cron-plus": "^1.3.0",
"node-red-contrib-device-stats": "^1.1.2",
"node-red-contrib-dns": "0.0.4",
"node-red-contrib-fs-ops": "^1.6.0",
"node-red-contrib-i2c": "^0.7.2",
"node-red-contrib-linux-network-stats": "^0.2.1",
"node-red-contrib-loop-processing": "^0.4.0",
"node-red-contrib-md5": "~1.0.4",
"node-red-contrib-os": "^0.1.7",
"node-red-contrib-play-audio": "^2.5.0",
"node-red-contrib-ring-buffer": "~0.10.0",
"node-red-contrib-simple-gate": "^0.3.1",
"node-red-contrib-simple-queue": "^1.1.0",
"node-red-contrib-smartlifeair": "~1.0.1",
"node-red-contrib-speedtest-updated": "^2.0.2",
"node-red-contrib-traffic": "^0.2.1",
"node-red-contrib-ui-led": "^0.3.3",
"node-red-contrib-weather": "^0.1.2",
"node-red-dashboard": "^2.23.4",
"node-red-node-email": "^1.8.0",
"node-red-node-mysql": "^0.1.1",
"node-red-node-openweathermap": "^0.3.1",
"node-red-node-pi-gpio": "^1.2.0",
"node-red-node-pi-gpiod": "^0.1.0",
"node-red-node-ping": "^0.2.1",
"node-red-node-random": "^0.2.0",
"node-red-node-serialport": "^0.11.0",
"node-red-node-smooth": "^0.1.2",
"node-red-node-snmp": "0.0.25",
"node-red-node-ui-list": "^0.3.3",
"node-red-node-ui-table": "^0.3.6",
"os": "^0.1.1",
"speedtest-net": "^2.1.1"
}
}
Side note... really wish NPM would update the version # (i.e. "version": "0.0.1") in the package.json in some way so audit of package.json could be easier. 
Just asking if this is expectation forward?
I"m not sure what we're meant to be seeing here?
What version of node.js is this? What version of npm?
could that have moved Node somehow
What "Node" do you mean? node.js? Running npm install against your package.json file won't touch anything globally installed, or your node install.
When would you want it to do that? NPM doesn't know about changes to your application. It can't decide that installing a new module warrants a change in version string for your application. Either way, that's a question you can take up with npm - it isn't something we have any responsibility for.
This sounds more like a misconception how npm works. I cannot say based on your post which commands you've ran and where. npm list lists packages installed under the current directory you are in.
You're listing @types/node-red which is the package containing TypeScript types for Node-RED. Any package you have installed on the directory can have a dependency on a specific version of the types module. This does not have anything to do with where Node-RED is installed in and definitely not where it's run from. Basically you could have any version of Node-RED installed inside your .node-red directory. If Node-RED is installed on your Pi with the official script and run using systemd then the globally installed version (under /usr/lib/node_modules) is used and the version inside your .node-red dir is just waste of space.
@ristomatti
So nothing changed with 1.2.2... Cool. Thanks for confirming. So I have a npm mystery again. It happens.
I have a flow that checks for newer versions of Node, NR, npm, etc. It has been working well for some time. But today, something changed, throwing a wrench in my flow. One of the check points my flow uses is npm list to see what npm thinks is installed and where.
Right after I updated to 1.2.2 that same line of code stopped working. This is not a dig against NR, only that it appeared npm did something odd. But it could also have been if something in the standard install had changed with 1.2.2. I only install NR via the official Pi script method. Including how said script installed Node, npm, etc. It make no sense that somehow something was global now was not global, hence the working command was failing. So, I asked the question I asked.
And, yes I know very well how npm works having spent 10s of hours working with it, to try to get it to or work correctly consistently. It has many issues, and quirks, etc. Even to this day, after 100s of executions npm still does some surprising things.
It is not one of my favorite tools. Just this morning I ran npm install against my master copy of package.json, it completed with no errors or warnings. And what did I find... that the node-red-serialport module was not installed, yet it was clearly qualified in the package.json, under ~/.node-red/ on a new Pi image. So out of 40 odd modules installed, one was not? That is just one example of how npm does odd things at times. I have yet to find any 'batch' method with npm that is well behaved.
Not surprisingly and the likely explanation is here:
Yeah, and why @knolleary noted in another thread, npm rebuild is often required and recommended. Like I said, just when I think I have got npm figure out... curve ball!
Can you explain exactly what you mean by that please? I would not expect to see node-red at all in package.json if you are using the usual script.
[Edit] Belay that, I misunderstood what you meant. I see now you meant the file is under ~/.node-red. I am still confused though, what exactly did you have in package.json that did not install the serial node?
The package.json was created via npm install of individual modules. I then copied the package.json to a new Pi OS install, i.e. /home/pi/.node-red/, where I had just run the NR install script (for 1.2.2). I then ran npm install. All the modules installed (or I should say any not already installed, installed) but one, serialport. I restarted nodered, checked the palette via the UI, editor, and serialport showed not installed.
I have seen this before a few times where, one or more modules just, for no clear reason do not show as installed. Because npm is quirky, I just roll my eyes and move on. I used to double check the SD card in use, and do a few other things, but with one exception (i.e. a bad SD card) I still have had a few npm installs (via various methods) do odd things.
I know one thing for sure... running npm install "module" "module" "module" "module" almost always fails.
I know using a script that does npm install "1 package" then npm install "2 package", etc. Almost always is successful.
Thus far, npm install using package.json has failed twice, once a bad SD card, and the subject under discussion here.
This morning I created a new bash script that I can run to confirm which modules from a master list are already installed, noting global or local, or if needed be installed. I still plan to use the package.json approach, but if I do find something missing, I can run my bash script and address the issue. The script also captures the installation details for future reference.
If I as really motivated, I would write an ansible playlist to do the npm install via package.json then always run my new script... but I hate using ansible unless it really is the only option.
The reason I had to ask was because initially you said that you had node-red-serialport in package.json and that it didn't install it. If package.json had included that then it would not have been in the least surprising that it did not install as there is no node called that. It is node-red-node-serialport. What I didn't know was whether the typo was in the post here or in package.json. Since it appears that it was in the post here then the puzzle remains.
I would just say that the method I use to restore sytems is to provide the appropriate package.json and then run npm install and I have never had a problem. Actually that isn't quite true, I also provide package-lock.json which ensures that the exact same versions of nodes are installed, so that might be a factor.
I did not edit the json... you are correct, I mistyped the name of the package, should have checked the package name, in hindsight.
You raise a good point, I should be using the lock file for strict standardization, you mentioned that you use the lock file some time ago, and I had yet to change my process. My intention since I was creating 'new' image(s), was that I could get the latest versus last used variant of said packages, i.e. package versus package-lock sourcing.
I have changed my update flow logic, so that has an expectation of globalization versus localization for modules but does not explicitly require it, except for NR query. Thus the flow will not fail if something is global or local for some unexpected scenario. Still not sure how I got a rogue 'node' install, but it had to be something I did at some point.
If anyone is interested here are the 'preferred' exec node commands to validate node, NR, and npm versions installed and how I check for newer versions. Checking the tags for NR is also valid as you noted as well in past discussion.
Node Red (available versus active)...
npm search node-red | grep Low-code | cut -d '|' -f4-5
npm ls -g --depth=0 | grep node-red | cut -d '@' -f 2
Node (available versus active)...
npm info node | grep latest | head -n 1 | cut -d ':' -f2
node -v
NPM (available versus active)...
npm info -g --depth=0 npm | grep 'latest' | grep -v 'latest-' | cut -d ':' -f2
npm --version
If a 'global' query fails, the flow does the same query 'local' for the available queries above. I would standardize the above using npm info as base method, but for the 'Low code' or 'editor' information that only appears to be visible via the search option? Thus I can get the release date of NR. Oh, the 'next' for 1.2.2 still shows beta 1.2.0-beta.1, for npm info (checking the tags) that would break my flow logic).
Are you sure it is a good idea to update npm? Since npm is installed as part of the nodejs install (using the standard script) I have always assumed that if an npm update is required then it will come automatically with the next nodejs update (via apt upgrade). I wonder if there are issues using a version of npm later than the one shipped with the nodejs in use.
I can't give a definite answer to that but I've been working with Node.js now for ~5 years and I've always updated npm with npm install -g npm when it starts nagging a newer version is available. I've never had any issues with doing so.
Perhaps if you want to do it the proper way, check it's release notes what the update has. It might be bug fixes, security fixes, features useless to you etc.
On some Raspberry Pi's I have, I might not upgrade it and never had any issues with that approach either. But you are correct in that it gets bundled with Node.js releases. It's just not to my understanding tied to a specific version.
I see that there is an npm 7 available now, and there have been comments in another thread that this introduces breaking changes. If I upgrade using npm install -g npm will that pull in 7? Perhaps not, it may only install the version tagged latest. However, at some point presumably 7 will be tagged latest.
Yeah, I always upgrade npm the same as you do, when I actually update it, unless I am running the NR script on a clean image of course and it does the initial install of npm.
The goal right now is just to flag when the active version on the Pi device is different than the available version. This does introduce a potential issue, as @Colin noted just above, that if I am not careful I could get either node.js or npm ahead of the supported version(s) for NR.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
