Help, I messed up weather-icons-lite

Hi, I messed up.

when I updated with "npm i weather-icons-lite" it updated and I could see the changes in css.
but node-red didnt reconize them.

At some point, after I messed up..... when I now update a palette in nodered it cant update because of missing writeaccess to weather-icons-lite.

when browsing filesystem in node-modules I can see weather-icons-lite is a symlink folder.
I then tried to delete this symlink but now I cant install the weather-icons-lite, and when ever I update another npm package from the node palette it keeps creating this symlink.

Do any of you have an idea on how I unmess this trouble I put myself in?

I have tried npm rebuild in the .node-red folder.

You shouldn't really be installing or updating weather-icons-lite in this way, as it is a dependency within node-red-dashboard.

When the node-RED team update node-red-dashboard, the build process copies files from npm weather-icons-lite, and processes them as follows when installed on a pi;
The 2 font files are installed in /home/pi/.node-red/node_modules/node-red-dashboard/dist/fonts, and the corresponding css is merged into the dashboard css file - app.min.css which is located /home/pi/.node-red/node_modules/node-red-dashboard/dist/css.

I would npm uninstall weather-icons-lite and await for the next version of the dashboard to be released, which will contain the css changes which you made a PR for.

v2.25.0 of the dashboard currently uses v1.5.0 of the w/icons. Your recent changes are in v1.6.0.

I kinda found out, too late about the build in css to node-red.

when trying to uninstall it says:

pi@raspberrypi:~/.node-red $ npm uninstall weather-icons-lite
npm ERR! code ELOOP
npm ERR! syscall open
npm ERR! path /home/pi/.node-red/node_modules/weather-icons-lite/npm-shrinkwrap.json
npm ERR! errno -40
npm ERR! ELOOP: too many symbolic links encountered, open '/home/pi/.node-red/node_modules/weather-icons-lite/npm-shrinkwrap.json'

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/pi/.npm/_logs/2020-12-20T14_18_23_858Z-debug.log

and the end of debug log

17 silly saveTree └── weather-icons-lite@file:node_modules/weather-icons-lite
18 verbose stack Error: ELOOP: too many symbolic links encountered, open '/home/pi/.node-red/node_modules/weath$
19 verbose cwd /home/pi/.node-red
20 verbose Linux 5.4.72-v7+
21 verbose argv "/usr/bin/node" "/usr/bin/npm" "uninstall" "weather-icons-lite"
22 verbose node v12.19.1
23 verbose npm  v6.14.10
24 error code ELOOP
25 error syscall open
26 error path /home/pi/.node-red/node_modules/weather-icons-lite/npm-shrinkwrap.json
27 error errno -40
28 error ELOOP: too many symbolic links encountered, open '/home/pi/.node-red/node_modules/weather-icons-lite/n$
29 verbose exit [ -40, true ]

I'm stepping outside of my comfort zone here as I've never encountered ELOOP before...

I would stop node-RED, manually delete the weather-icons-lite directory, and then carefully edit the package.json file which is in your .node-red directory, deleting the line containing weather-icons-lite (create a backup first).

Then restart node-RED.

@TotallyInformation - do you agree Julian?

I think that personally, I would delete the whole node_modules folder from your userDir. You probably need to to an npm cache clean --force as well. (I think that's the command, I don't often use it so don't always remember it exactly). It is possible that the cache is causing the issue. Despite the horrid warnings you get when trying to run it, it doesn't do any harm.

Once you've done that, again from the userDir folder, run npm install and everything should come back nicely.

from userdir ~/ or from .node-red/ ?

It wont do any harm to my flows etc.?

By efault, the userDir is at ~/.node-red, it contains your flows and settings and more. That is where you install your nodes.

Just make sure you only delete the ~/.node-red/node_modules folder and all will be well.

Of course, always sensible to take a backup copy of key files/folders before messing with things :wink:

Unless the package.json file is edited and weather-icons-lite removed, it will be automatically installed again when as Julian says "run npm install".
But you should then be able npm uninstall it as normal.

Thanks Julian

weird stuff is going on...
in ~/.node-red/

renamed node_modules folder to node_modulesXXX
ran npm cache clean --force
ran npm install

Then did a list: ls node_modules/ and it shows that weather-icons-lite is still a symlink folder.

Have you had a look in your package.json file?

oh I will.....

though have to go now, thx for your help, will work on this later...

You will probably have a line similar to;

"weather-icons-lite": "file:../some-directory/weather-icons-lite",

If so, delete that line, and repeat what Julian suggested.

And you may have a package-lock file that you need to edit also.

editing the package.json file removing weather-icons-lite line and then deleted node_modules folder, clean cache and npm install.

Think it worked, now no weather-icons-lite symlink in the node_modules folder.

Thx all of you for rescuing me, now I just sit tight and waiting for the next update of node-red.

you don't need the whole of Node-RED - just the next version of node-red-dashboard.
And it will probably be this week.

2 Likes

Drat I always forget to remind people to delete that as well.

In fact, at least with npm v6.14.8, it is not necessary to edit package-lock.json after editing package.json. package.json determines what should be installed and may specify a range of versions that are acceptable, package-lock.json specifies exactly which version it should be (or is). If an entry is removed from package.json and npm install is run then the package spec is removed from package-lock.json.

Personally, I've had lots of problems with package.lock in the past. If I have an npm problem, deleting it is pretty much the first thing I do. It gets re-created anyway next time you install something. It is only really useful if distributing your code anyway.

I was just pointing out that it should not be necessary in the situation we have here.
I haven't had any problems with the lock file, but quite possibly I just haven't hit the appropriate edge cases.