FYI got an issue after installing linter plugin

@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 :slight_smile:
But that's not the big issue here :slight_smile:

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 :slight_smile:

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.

1 Like

aah - your right
image

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 :slight_smile:

#CaseClosed :slight_smile:

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

image

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 :slight_smile:

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 :slight_smile:

{
  "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. :slight_smile:

I think it's really not worth putting any more time and effort in :slight_smile:
Apart from an intellectual exercise :slight_smile:

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
image

OK, I give up!

1 Like

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

2 Likes

:grinning: 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.

1 Like