Publish package to npmjs registry

[alexojegu]

I want install zwave-js-ui on a LXC Alpine container, that it is running on a OpenWRT host.

It seems easier to install node.js from an APK and run npm -g install zwave-js-ui than download the packaged version, extract, etc. But above all it seems much easier to maintain and update it:

npm -g --depth=0 outdated
npm -g update zwave-js-ui

or maybe:

npm -g update

I don't know if I'm missing something, I don't usually use globally installed NPM packages. But I think it should work and it would be more comfortable.

https://docs.npmjs.com/updating-packages-downloaded-from-the-registry#updating-globally-installed-packages

[robertsLando]

@alexojegu I thought about that but I'm not sure how to handle persistent data stored on store directory...

[alexojegu]

I haven't used zwave-js-ui yet so I don't know how it persists the data in the store (I'll try to try the packaged version this afternoon). But I don't quite see the difference between npm -g update and deleting the Docker container and creating a new updated container or download the packaged version, extract the .zip and doing the same with a new version.

If the problem is the path, perhaps a required option in setting would be useful to configure it and save it in a JSON outside the store (maybe on app root path), or a STORE_PATH environment variable.

[robertsLando]

yeah but you should configure that path someway, maybe by creating a service that starts the ui like with pm2

[alexojegu]

Yeah, I was thinking of using pm2 to start it automatically. But I think it would also be worth configuring the variable in /etc/environment or perhaps even starting with ZWAVE_STORE_PATH="/some/path" node zwave-js-ui.

[robertsLando]

pm2 allows to specify env vars

[alexojegu]

I'll wait for the NPM registry release, the packaged version doesn't seem to work in my (armv7l) Alpine container:

home:~/zwave$ uname -a
Linux home 5.15.134 #0 SMP Mon Oct 9 21:45:35 2023 armv7l Linux

home:~/zwave$ wget https://github.com/zwave-js/zwave-js-ui/releases/download/v9.3.2/zwave-js-ui-v9.3.2-linux-armv7.zip
Connecting to github.com (140.82.121.3:443)
Connecting to objects.githubusercontent.com (185.199.108.133:443)
saving to 'zwave-js-ui-v9.3.2-linux-armv7.zip'
zwave-js-ui-v9.3.2-l 100% |*******************************| 60.5M  0:00:00 ETA
'zwave-js-ui-v9.3.2-linux-armv7.zip' saved

home:~/zwave$ unzip zwave-js-ui-v9.3.2-linux-armv7.zip 
Archive:  zwave-js-ui-v9.3.2-linux-armv7.zip
   creating: store/
  inflating: zwave-js-ui

home:~/zwave$ ./zwave-js-ui
-ash: ./zwave-js-ui: not found

home:~/zwave$ ls -la
total 286408
drwxr-xr-x    1 alejandr alejandr       100 Nov 15 21:01 .
drwx------    1 alejandr alejandr        42 Nov 15 21:00 ..
drwxr-xr-x    1 alejandr alejandr         0 Nov 15 21:01 store
-rwxr-xr-x    1 alejandr alejandr 229776590 Nov 15 21:01 zwave-js-ui
-rw-r--r--    1 alejandr alejandr  63501340 Nov 15 21:01 zwave-js-ui-v9.3.2-linux-armv7.zip

In my (x86_64) Arch Linux desktop does start.

[robertsLando]

https://www.npmjs.com/package/zwave-js-ui

Docs: https://zwave-js.github.io/zwave-js-ui/#/getting-started/other-methods?id=npm

[alexojegu]

In a quick test it is working as a charm, thank you.

I can suggest that at some point STORE_DIR be renamed to ZWAVEJS_STORE_DIR for consistency and to limit the possibility of collisions with other environment variables.

And if you don't mind a quick question: mosquitto vs aedes with aedes-persistence (I see you are part of the development team) for a domestic system, with few resources but also few nodes (At some point I intend to integrate zwave-js with homebridge, so I imagine I'll need an MQTT broker.).

Thanks again.

[robertsLando]

@alexojegu Thanks for the feedback about NPM.

About aedes vs mosquitto, them are both good brokers but the answer to your question is that it depends on your needs.

If you need to customize your broker (by writing custom auth for example or handle all kind of possible events) aedes is the way, if you just need " a broker" I would opt for mosquitto or aedes-cli that are easier to use (just one command to install and another to run them and a config file to configure).

Giving that this is a domestic system all the thoughts related to the speed doesn't make any sense as the difference in speed is only seen with very high loads of msg/s