Quick question regarding “correct” version(s) of openhab-js relative to the installed openhab version. I’m running 3.4.2 release with Java 11 in a Proxmox vm on x64. Most everything is installed/maintained via openhabian.
According to CHANGELOG.md for openhab-js, this is either version 2.1.1. I believe this is a very old openhab-js version that doesn’t match well against openhab 3.4.2. When I run openhabian, it says there’s a newer version to install. I install it, but the CHANGELOG doesn’t change, and openhab-js stays the same version.
I know how to manually upgrade openhab-js, but I’m wondering if openhabian is not upgrading it for a reason? Trying to figure out the best course of action…
I’m not sure if maybe openhab-js is not upgrading because I’m still running Java 11 and should upgrade Java (but I have some older Nashorn rules still), or if perhaps this is the correct openhab-js version for openhab 3.4.2, or there is an issue with openhabian.
Is it advisable to manually upgrade openhab-js via npm at this point, troubleshoot openhabian as to why it’s not actually upgrading, or am I just where I need to be at this point? Keeping tabs on various components / versions is getting a bit tricky for me with the goal to minimize breaking changes while ensuring I’m staying up to date on the stable release…
There might be something wrong with the way openHABian does the update. There is some weird behavior that I’ve run into where npm will keep the old version because of the way it sets up the package-lock.json file by default.
Does it work if you uninstall it and reinstall it manually?
If that works for you, please open an issue on openHABian so we can work though how to handle the case where openhab-js changes major version numbers. I think npm is fine upgrading from 3.x.x to 3.x.x+ but needs an uninstall and reinstall to upgrade from 3.x.x to 4.0.0 (in your case, it may not want to go from 2.1.1 to 3.4.2 actually).
Note that you can never go wrong using the version of the library that comes with the add-on so it would not be wrong to not have openhab-js installed separately at all.
I think openhab-js 4.0.0 will work in OH 3.4.2 but openhab-js 3.2.4 will definitely work. This is unrelated to the version of Java. npm doesn’t know nor care about Java.
Yes.
That’s why I recommend not installing openhab-js yourself and instead use the version that comes with the add-on, except when there is something in a new version of the openhab-js library you know you need. The version that comes with the add-on is guaranteed to work with that version of the add-on and new releases of the add-on come with new releases of the library.
I haven’t yet tried running openhabian in debug mode. Worst case, I can just manually upgrade it via npm, but I figured I’d get some opinions on whether it was a good idea or not first.
I haven’t tried uninstalling and reinstalling it via npm. I’ll try that route first. I’ll shoot to move in sync to 3.2.4… Assuming that works, I’ll open an issue on OpenHABian. If I recall correctly, I may have actually installed openhab-js manually first. It may be a permission issue (user openhabian vs. user openhab doing the installs…)
I’ll try the manual upgrade path and see what happens. I checked the breaking changes going to 4.0.1, and I don’t think it’s going to effect me negatively. I’d like to work with the metadata changes, but not at the expense of creating too many problems.
Thanks for confirming that I’m definitely running too old a version of openhab-js. I never really noticed until openhabian-config kept “upgrading” openhab-js, but after a few rounds, it was pretty obvious that nothing was changing…
I’ll have to work with this more tomorrow, but some interesting observations.
I was able to upgrade to openhab-js v3.2.4 and openhab_rules_tools v2.0.0. I had to specify the version. A regular npm upgrade would not work. Openhabian also will not work. No errors seem to be thrown that I can find…install acts as it should, but checking package.json in each shows no upgrade unless it is specified.
If anyone else has a similar problem, consider looking at specifying the version number (npm install package@x.y.z). Not sure what’s going on yet, but I’ll have more time to take a look tomorrow. Not an openhabian issue…
Quick edit: After installing npm-checkupdates package globally and checking local packages for new versions, I was able to upgrade (went to openhab_rules_tools 2.0.1) without specifying a version number… Perhaps this has to do with package locking? In any event, if someone else has an issue like this, maybe this can help.
Be careful there. First of all, 2.0.0 had a big and I released 2.0.1 less than an hour later. Also, 2.0 depends on openhab-js 4.1. As long as you don’t use some of the new stuff added to helpers.js I think you’ll be ok.
But I’m not sure if they’re are changes in either library that makes it only work with OH 4.0 or not. OH 4 is a big moving target that both libraries are chasing.
I’d be interested to know if it works, but you might need to downgrade ohrt 1.2. Most of the changes are additions (so far) though I did fix two bugs, one in countdownTimer and one in loopingTimer.
As @rlkoshak already said, this it the reason why it’s not recommended to manually install. The addon always comes with an included version that works perfect with this openHAB version, and autocompletion in the UI only works for the included version. For other versions, you may get wrong/incomplete autocompletion.
IIRC correctly, version 4 of openhab-js does not depend on any openHAB changes, I am using it with my 3.4.2 and it works fine.
So far, so good with 2.0.1 and OH 3.4.2. I’m not using some of the newer stuff. If I hit roadblocks, I’ll downgrade - and if I find something that “should” work but doesn’t, I’ll let you know…
I wonder if we need to have more control than that for the end users.
Right now, if someone were to upgrade openhab_rules_tools but are using the openhab-js library that comes with the add-on there will be incompatibilities and some things won’t work. I think I am going to add version checking across my library to report this incompatibility but I wonder:
does openhabian-config let the end user choose the version of the libraries to install?
does it attempt to upgrade automatically or only by command through openhabian-config?
There are I’m sure some things on my end I can do to make these upgrades a little easier on end users. I’m already planning on adding version checking to the constructors for the library classes (and perhaps elsewhere) to report when the versions are too old (like I’m adding to the rule templates) but perhaps there are other things I can/should do. Maybe my verison numbers should follow the openhab-js version numbers, or go out of my way to remain backwards compatible (which I already try to do but new additions to openhab-js are just too good not to use).
Openhabian-config only reports that there are newer versions of openhab-js and openhab_rules_tools. It doesn’t state a version - it just asks whether you want to upgrade to newer versions and reports if there are breaking changes to review for an upgrade. All of the various moving parts / keeping right versions can get to be tricky for both devs and users. There seems to be a lot of room for error given that it’s difficult to know what version(s) of what packages are compatible with what OH runtimes. It takes some digging - or in this case - asking the question because it’s not entirely clear.
If you declare openhab-js as dependency npm should install the version defined in openhab_rules_tools package.json.
But I’m not sure if that would mean that everything else also gets a new openhab-js version.
No — implementing this would be quite complicated since we’d have to perform several npm commands and parse the response. But when I recently fixed the installation, I made openhabian recognize breaking changes in the npm modules for JS Scripting (given that semver is followed): if the major version changes, the user is warned for breaking changes and asked if he really want to upgrade the libraries.
If the npm package is installed, it attempts to automatically upgrade it when the openhabian-config tool is opened. See my section above for breaking changes.
I wonder how it gets the list. I need to look into that.
I’m trying to address that some with changes I’ve made and requested and this discussion.
I can say that for OH 4 and beyond, openhab_rules_tools will check the version of openhab-js and throw an exception if it’s too old instead of ransom errors. That should help.
When I do that though it forces openhab-js to be installed under node-modules. npm can’t tell that the version in the add-on is there, sees it’s missing and installs it. That’s why I stopped doing that.
In short the answer is yes, it means everything else also gets the new version.
Only in so far that it doesn’t depend on an openhab-js version that depends on a specific version of OH (e.g. cache).
