@cymplecy you hadn't been manually adjusting package.json or package-lock.json had you before it reverted the version? Or restored something from a backup or similar? If you had accidentally changed the node-red dependency in package.lock then the next time you used npm it would have reverted node-red without actually telling you (I think).
Just in case you haven't followed the whole thread
I was running 2.1.3 as alternate install
I ran the linter plugin instructions
The install seemed to end up being downgraded to 1.3.5 and wouldn't start properly
I copied the whole folder to another folder and that's when I ran the update commands
I understand that you are saying that I ran the wrong update commands - fair enough
But that's not the big issue here
The issue is why did running the linter plugin installer instructions cause the downgrade to 2.1.3 to 1.3.5
No
as said previously - this install was copied from win10 at v1.3.5 and then I upgraded it to 2.1.3 on the pi4
So it is a very mangled install
The only thing I can think of is that somehow package.json had the wrong node-red version dependency in it, and then when you used npm to install the debugger it kindly reverted node-red for you.
aah - your right
and then Julian telling me off for not updating properly squares the whole circle
I un-doubtably did not update the original 1.3.5 to 2.1.3 properly and when I've run the linter plugin install - its gone - hang on - this should be at 1.3.5 - I'll sort that out
Well done to you both
#CaseClosed
I don't understand. If you run
npm install --production --unsafe-perm node-red@2.1.3
it should put that version into package.lock. If you don't specify a version it will install the version in package.lock.
It doesn't on my setup
package-lock.json just has loads of 1.3.5 references
I think, given the lifetime history of these flows, its time for me to manually recreate my flows onto a standard install and not try to work out any further why things doesn't seem to work 100%
At least its all working at moment so I can take my time
Thanks for all the help
Ah, that is the editor api, not node red itself. Can you post the full package.lock please. Copy/paste. Meanwhile I will give it a go myself.
Its too big to paste in
Sorry, I didn't mean package.lock, I meant package.json. That explains why it is too big.
already sent
{
"name": "node-red-master",
"version": "1.0.0",
"description": "Test environment for developing Node-RED flows",
"main": "node_modules/node-red/red.js",
"keywords": [
"node-red"
],
"author": "Julian Knight",
"license": "MIT",
"scripts": {
"start": "node node_modules/node-red/red.js --userDir ./data",
"admin": "node node_modules/node-red-admin/node-red-admin.js",
"inspect": "node --inspect node_modules/node-red/red.js --userDir ./data",
"update": "npm run update-master",
"check": "npm run check-master",
"check-master": "npm outdated",
"update-master": "npm install --production --unsafe-perm",
"check-data": "cd data && npm run check-data",
"update-data": "cd data && npm run update-data",
"restart": "sudo systemctl restart node-red",
"log": "sudo journalctl -u node-red -f -n 0 -o cat",
"adminui": "start http://localhost:1880/red/",
"ui": "start http://localhost:1880/ui/",
"patch": "npm version patch -m \"Patch version bump to %s\" ",
"minor": "npm version minor -m \"Minor version bump to %s\" ",
"major": "npm version major -m \"Major version bump to %s\"",
"postinstall": "node ./system/postinstall.js",
"win-tag": "git tag -a v%npm_package_version% -m \"Release v%npm_package_version%\"; git push origin --tags",
"tag": "git tag -a v$npm_package_version -m \"Release v$npm_package_version\" && git push origin --tags"
},
"dependencies": {
"do-red": "~0.1.7",
"node-red": "^1.3.5",
"node-red-admin": "*",
"node-red-contrib-actionflows": "~2.0.4",
"node-red-contrib-aggregator": "~1.5.0",
"node-red-contrib-alexa-home-skill": "~0.1.17",
"node-red-contrib-alexa-notifyme": "~1.0.1",
"node-red-contrib-arp": "0.0.2",
"node-red-contrib-audio": "^1.0.2",
"node-red-contrib-bigtimer": "~2.2.5",
"node-red-contrib-cast": "~0.2.15",
"node-red-contrib-color-convert": "0.0.5",
"node-red-contrib-components": "~0.1.6",
"node-red-contrib-config": "~1.1.2",
"node-red-contrib-counter": "~0.1.5",
"node-red-contrib-digitaloak-mqtt": "~1.0.4",
"node-red-contrib-dsm": "~0.14.1",
"node-red-contrib-fan": "~1.0.2",
"node-red-contrib-flatter": "~1.1.0",
"node-red-contrib-google": "~0.2.0",
"node-red-contrib-google-sheets": "~0.1.0",
"node-red-contrib-image-tools": "~0.2.5",
"node-red-contrib-ip": "~0.1.0",
"node-red-contrib-moment": "~3.0.3",
"node-red-contrib-mqtt-broker": "~0.2.4",
"node-red-contrib-mqtt-dynamic": "~1.0.9",
"node-red-contrib-msg-resend": "0.0.8",
"node-red-contrib-msg-router": "0.0.3",
"node-red-contrib-mytimeout": "~3.0.1",
"node-red-contrib-natsio": "~0.2.0",
"node-red-contrib-nbrowser": "~1.1.4",
"node-red-contrib-nexmo": "~3.0.8",
"node-red-contrib-ngrok": "~0.1.1",
"node-red-contrib-nora": "0.0.30",
"node-red-contrib-play-audio": "~2.3.2",
"node-red-contrib-pushstaq": "0.0.6",
"node-red-contrib-python-function": "0.0.5",
"node-red-contrib-queue-gate": "~1.5.3",
"node-red-contrib-remote": "~1.1.3",
"node-red-contrib-remote-gate": "github:drmibell/node-red-contrib-remote-gate",
"node-red-contrib-samsung-tv-control": "~1.1.6",
"node-red-contrib-satellites": "~0.3.1",
"node-red-contrib-simple-gate": "~0.3.1",
"node-red-contrib-simpletime": "~2.10.0",
"node-red-contrib-skyremote-new": "~0.1.1",
"node-red-contrib-smartlifeair": "~1.0.11",
"node-red-contrib-stoptimer": "0.0.7",
"node-red-contrib-string": "~0.2.2",
"node-red-contrib-sun-position": "~0.2.11",
"node-red-contrib-telegrambot": "~5.5.2",
"node-red-contrib-tgr-jsonata": "~1.0.2",
"node-red-contrib-tuya-smart": "~1.2.0",
"node-red-contrib-unifi": "~0.1.13",
"node-red-contrib-web-worldmap": "~1.3.6",
"node-red-contrib-zip": "~1.0.0",
"node-red-dashboard": "~2.9.6",
"node-red-node-arduino": "0.0.18",
"node-red-node-base64": "~0.1.3",
"node-red-node-dropbox": "~1.0.2",
"node-red-node-email": "~1.7.8",
"node-red-node-ping": "0.0.16",
"node-red-node-pushbullet": "0.0.14",
"node-red-node-pushover": "0.0.17",
"node-red-node-random": "~0.1.0",
"node-red-node-serialport": "~0.10.3",
"node-red-node-snmp": "0.0.21",
"node-red-node-sqlite": "~0.4.3",
"node-red-node-twitter": "~1.1.5",
"serialport": "^9.0.8"
},
"engines": {
"node": ">=8.16.0"
},
"browserslist": [
"> 0.5%",
"maintained node versions",
"last 2 versions",
"not dead",
"not ie < 11"
]
}
That is not what I expect to see in package.json, and as you can see it has node-red 1.3.5 in the dependencies. @TotallyInformation is this a hangover from using the alternate install? I don't see how package.json can look like that after running npm install --unsafe-perm node-red@2.1.3
I think its borked due to its long journey down the years from version to version and computer to computer.
I think it's really not worth putting any more time and effort in
Apart from an intellectual exercise
It currently works and I'm going to manually redo all the flows in a standard install
What better reason is there?
Can you check that you are able to edit and save that package.json please. I wonder if it has somehow got write protected.
Yep full able to read/write
OK, I give up!
It is a mix of things. The alternate installer installs node-red to a master folder and uses a sub-folder for the userDir. You would normally install contrib nodes to the userDir - but you don't have to. Node-RED is perfectly happy to have nodes installed in the higher level. This can be useful if you want to install some nodes that Node-RED authors can't mess with.
In this case, it looks like most nodes have beeen installed manually into the master folder - it works like that just fine, you just can't use the package manager inside Node-RED to manage the nodes.
Understood, thanks. I didn't realise the alternate installer used that structure.
Just to put things into perspective;
I have Node-RED running on Ubuntu 20, which is running in a VM on a Windows PC. I used TotallyInformation's installation method and I have also upgraded Node-RED several times using npm install --unsafe-perm --production node-red
(as shown on his GIT page) with no problems. The only time I have used the @version is when upgrading to a Beta version of Node-RED.
This doesn't help with the current problem at all, but I thought I would mention so that anyone reading the thread didn't get the notion that the alternate-node-red-installer
would cause them problems with upgrades to Node-RED
Of course not!!
And it shouldn't surprise anyone at all that I run multiple versions of Node-RED across multiple platforms using my alternate installer and I've never had any problems either.
The approach is a very simple and reliable one that keeps everything well organised, avoids any issues with global/admin permissions, allows multiple different versions of Node-RED to be run in parallel and makes everything very easy to back up and restore.