Oh no, I can’t hear myself speaking on the video… and it’s not the right window that was recorded… what a computer expert I am!
Oh dear. I’ll try this weekend with the documentation you created (I read a README or a post somewhere) and I’ll let you know if I need more documentation.
Oops! 
Well, at least post your presentation here 
The presentation is here
Sorry!! I just finished the job!! Well, missed it ^^ So I’ll do as @cicoub13 with the presentation as support and we’ll review!! Thanks for all the details in any case @AlexTrovato
Following the merge of @AlexTrovato’s PR on Cypress tests, we’ll be able to add tests and make progress on the migration to the new version of preact-cli, as well as remove some heavy libraries!
For fun, I looked a bit at what was taking up space in the JS bundle
In the node_modules of the main bundle:
I noticed that the « vis » library takes up a lot of space, and above all it is not correctly « route split ». Given that this library is only used in the Zwave service, I thought the library was only included in the page bundle.
However, as the preact cli doc says (GitHub - preactjs/preact-cli: 😺 Your next Preact PWA starts in 30 seconds. · GitHub):
I think there must be something wrong with the code-splitting in the way we currently import files. We’ll need to investigate
Edit: I came across this great blog post:
I did a small analysis of the packages that are slowing down our frontend the most:
| Library | Size | Action |
|---|---|---|
| vis-network | 509 kb | To be removed and replaced by a simple table in the Z-Wave integration |
| vis-data | 220 kb | To be removed and replaced by a simple table in the Z-Wave integration |
| date-fns | 240kb | To be replaced by dayjs (already used in the front) |
| leaflet | 408 kb | See if we can import it dynamically only in the maps view + signup form + home settings |
| cropper | 110kb | See if we can import it only in the signup + settings page |
| tagify | 59 kb | See if we can import it dynamically only in the scene view |
| @jaames/iro | 27kb | See if we can import it dynamically? |
On another topic, there is also the lib « tabler-ui » that we use for the UI which has released a lot of new features recently, at some point we will have to migrate to it but it will be a big task!! 
Well, for date-fns in the end it’s not as simple as that…
The lib « react-datepicker » depends on it to format its UI in French. I don’t think it can be changed.
I will try to leave only the minimum of the lib…
Nothing more to add
Once we’ve done a bit of tidying up, we’ll be able to add this to the CI:
I don’t know if this is related, but when you install gladys for the first time and you want to talk to her via the chat, she doesn’t respond and if I refresh the page, it takes easily 15s to load, and I get my answer delayed, so above my question… I reproduce the thing every time, only I forgot to screenshot.
@Jean34 I don’t know if it’s related, we can discuss it in the « various bugs » topic (or a new topic if you prefer)
You planning to do a new dev release for the bug I told you about yesterday for the weather box? If so, I’ll reproduce the bug on the other discussion, yes 
I just launched a dev build
I made a PR for a HIGH severity server-side vulnerability: security(server): CVE-2021-23358 by cicoub13 · Pull Request #1195 · GladysAssistant/Gladys · GitHub
What do you think about it? Is it better to update dependencies as we go (when we see them)? Or rather have an « update » session once a month?
I think Cypress will allow us to update dependencies more peacefully when it has greater feature coverage 
It depends on the vulnerability and the impact
In Gladys currently, for all vulnerabilities with a criticality >= HIGH for production dependencies (not devDependencies), the build is completely blocked (we run npm audit on every push) (see Gladys/.github/workflows/docker-pr-build.yml at master · GladysAssistant/Gladys · GitHub), so we already have an automated process for dependencies going to production.
In this case, it’s a devDependency, so it’s not a dependency that goes into production, it’s just a local build tool, so the vulnerability has no security impact on Gladys.
Indeed, doing a little pass from time to time on these kinds of devDependencies, I think that’s the right approach
Thanks for the clear response. Great for the blocking build for real dependencies 
Hello everyone!
I spent all of Thursday and Friday doing stability, updates, cleaning, and big news: I managed to upgrade to preact-cli 3.xx!!!
It’s just crazy, it changes everything:
- No more weird bugs when developing (components that duplicate)
- The JS bundle is built for modern browsers and intelligently loads polyfills. This makes a real difference in bundle size. We remain compatible with > 99% of browsers in circulation, don’t panic My target for Gladys in general is to be compatible with Firefox, Chrome, and Safari. That’s already good for the project we have.
- Ability to load components asynchronously and thus not have a huge central bundle, but smaller bundles. We’ll see if we really want to separate the bundle by page. I did some tests to see what it would be like if all routes had separate bundles, and the user experience isn’t necessarily better: instead of having an initial load that’s a bit slower, the app seems slower when you navigate it because you have to make a request per route, and that results in hundreds of bundles instead of one. As the app is a PWA, it means the app has to update by making hundreds of sequential requests, which is slower, whereas when it’s a single bundle, it’s just one request (admittedly a bit slower, but only one request). I think we need to be smart: do this when necessary, on routes that really have very heavy components (example: the map with leaflet, that kind of thing)
I’m super happy with the result, the PR is here for those interested:
https://github.com/GladysAssistant/Gladys/pull/1242
Edit: I made a dev build if you want to test.
The Gladys demo site has also been updated to this new build
I’m using this build and haven’t encountered any side effects so far 
Great job!