Hi All, It’s high-time I posted here; I want to let everybody know what I have been doing and plan to do next with my Frontend modifications
I have frozen the branch I am working on; and this is a nominal ‘rc1’ for a LW4.1 release; If you would like to Beta-Test this it is online here,
- I heartily recommend people to check this out, try importing an image or svg, set a cutting speed and generate some gcode.
- No need to do a full config unless you want to use it in anger. Later in the release process we will make electron builds available for users who want a more conventional experience.
If you spot or hit errors, please come back on a new thread in support channel
The preview link takes you first to a readme where I outline the User-facing changes, I have just put in nearly a months worth of work on the frameworks and dependencies, getting LW upgraded as far as I can. And I’m pretty happy with the results:
Current release (4.0.999):
npm audit gives 400+ lines of complaint and then says:
71 vulnerabilities (8 low, 48 moderate, 15 high)
4.1 Preview:
npm audit says:
found 0 vulnerabilities
(while security is not a huge concern for LW’s use-case this is a good indication that we are now on supported versions of our frameworks)
npm outdated lists 38 packages with updates available for the current release; for the preview I have got this down to:
[owen@hobbes LaserWeb4]$ npm outdated
Package Current Wanted Latest Location Depended by
babel-loader 7.1.5 7.1.5 8.2.3 node_modules/babel-loader LaserWeb4
bootstrap 3.4.1 3.4.1 5.1.3 node_modules/bootstrap LaserWeb4
react 16.14.0 16.14.0 17.0.2 node_modules/react LaserWeb4
react-bootstrap 0.31.5 0.31.5 2.1.2 node_modules/react-bootstrap LaserWeb4
react-dom 16.14.0 16.14.0 17.0.2 node_modules/react-dom LaserWeb4
react-redux 5.1.2 5.1.2 7.2.6 node_modules/react-redux LaserWeb4
react-rnd 8.0.2 8.0.2 10.3.5 node_modules/react-rnd LaserWeb4
react-select 1.3.0 1.3.0 5.2.2 node_modules/react-select LaserWeb4
redux 3.7.2 3.7.2 4.1.2 node_modules/redux LaserWeb4
redux-localstorage 1.0.0-rc5 1.0.0-rc5 0.4.1 node_modules/redux-localstorage LaserWeb4
So, some major upgrades till to go; but MUCH better than it was. I have focused on simpler in-place upgrades with minumum code changes. The suggested upgrades above all need some sort of more extensive re-architecting or refactoring in the codebase, And will be a target for the future.
My next steps are to
- Rename my branches, rebase and submit a PR.
- Write a definitive ‘Building Frontend’ guide and put this in the repo
- Get Production vs Devolopment builds working
- Start testing electron builds (appimages); these will undoubtedly need some changes to the Frontend and/or dependencies to get working.
One we can produce binary packages and have done some beta testing with these I hope (with @cprezzi 's help) to then make a main release with Frontend 4.1, lw-comm-server 4.1.1
5 Likes
Great work @easytarget !!
(edits from another testing round)
I was able to clone the easytarget-org/LaserWeb4, wrestle with Debian package system and make it work to a certain degree. Here are my notes:
- Before making any changes, save your machine profiles to a JSON file using the
Settings / Tools / Machine Profiles . This will save you the grief of reconfiguring everything. In my case this is all I needed to save the machine dimensions. GCode specifics and macros.
- In Debian Bullseye, I needed to add experimental and testing version. I also added pinning for nodejs and npm. Now I have nodejs v16.13.2 and npm 8.4.1
- Because of the lib dependencies, I had to use
apt install nodejs -t experimental and apt-install npm -t experimental to get to the version level desired. Also had to run apt install --fix-broken but I’m not clear why yet.
- Deleted package-lock.json
- Ran
npm install --force then npm run bundle-dev
- Also needed to git clone easytarget-org/lw.machines and easytarget-org/lw.materials into laserweb/src/data. At first I made the mistake of cloning original LW4 lw.machines and compile would throw an error.
- Went into
dist directory and ran python3 -m http.server 8001
- Note the port 8001. If I’d use port 8000, the Chrome cache would fight its way back. it also conflicts with lw.comm-server port. So if I point my Chrome browser to localhost:8001 and start the lw.comm-server using
nodejs server.js then there’s no fighting between the three applications.
At first the interface was somewhat slower than what I am used with the current dev-es6 main branch but eventually things settled. Note that I’m using a vnc connection with x11vnc so anything GL tends to bog things down on that link. I had to go pick a reasonable grid size (major spacing is set to zero?) and turn on Performance Display Cache to get things moving smoothly.
I also made a fresh git clone of LaserWeb4/lw.comm-server which I was able to run npm install and node server.js. At that point I had connection to my smoothieboard and was able to do the basic controls actions.
CPU wise I feel there’s a bit more CPU consumption. but once the Performance Display Cache is ticked on it goes to a low CPU load.
I still have quite a bit to tinker with, I’d like to bring my machine definition over to the new version. I always wondered where this was stored…? If I save the machineProfiles in Settings / Tools will it be compatible with this version?
Awesome work!!
1 Like
Thankyou for the feedback 
The ‘building the frontend’ guide I’m working on will have a whole section devoted to debian and it’s curmudgeonly outdated packages… err… I mean… on how to install node 16 on it. I’ve been testing this on a pi4 with /bullseye so I know the score 
though I’m a RHCE and fedora boy at heart.
Also the --force option to npm install is a pain but fixing it needs co-ordinated changes to several dependencies, so I’ve decided to live with it for present.
-If you want a laugh… try a simple bootstrap upgrade to 4.x (and nothing else), the result runs and is almost usable… it gives a taster of how many things will need fixing to get bootstrap to 4.x, and on which several other upgrades are blocked.
I should of mentioned the need to pull the machines and materials repos too… another pointer for the install guide.
I’ll double-check the major grid size, it should default sensibly (but I have worked in that area so ymmv, I do test regularly by first clearing cookies, localstorage and then a cache flush, hard reload, I haven’t noticed any issues with this, so I’m curious…
You can use tools->save settings to export your profiles from an older install and tools->import to get them them into the new version, nothing has changed there, it’s all json and any option not present in the imported file will be defaulted. You should probably double-check all the settings are as expected afterwards.
I started with RedHat and Slackware back in late '90 early '00. Haven’t touched RedHat in a long time, before the CE and Fedora stuff. I agree with you that Debian, as you pointed out, is slow getting new package versions to testing & stable. Most of the time I can get away with backports, but it happens I have to make a schizophrenic install. What I learned is if I’m forced to blend releases like here, you can almost be sure you won’t be able to apt update / apt upgrade smoothly, even less so for a major stable release, and I can only hope it’s a single use machine like LW4 should be installed to so the library dependency is limited.