Add build system from Meson to esbuild with efficient hot reload support for development

[KernelDiego]

📖 Summary

Modernizes the project's build system by migrating from Meson to esbuild and introduces a flexible, efficient hot reload workflow for both build and runtime. Several build modes have been added to support different development and deployment scenarios. Between applying a change and seeing it in Hyprpanel is less than 1s (In between builds and runs hyprpanel efficiently).

📊 Improvements

⚡ Build time: Compilation is now dramatically faster with esbuild.

📦 Bundle size: Reduced from ~3.3MB to ~448KB, achieving an almost 7.5x reduction.

⚙️ Simpler configuration: esbuild offers a cleaner, more maintainable setup.

🔥 Hot reload:

• build:watch: Watches for changes and automatically rebuilds.

• dev:watch: Watches for changes in compiled files and restarts the application.

• Enables real-time feedback and rapid iteration.

🧭 Multiple build targets:

• build:fast: Quick build with esbuild.

• build:dev: Builds and installs directly in the test directory (./dist).

• dev: Runs the app directly from the dist/ folder.

• start: Runs the currently installed system version from /usr/share/hyprpanel/.

• build: Adds command to compile with Meson

[KernelDiego]

Here is a small demonstration of hot reloading

hot_reload.mp4

[davfsa]

I have some issues with this pull request:

1. It is clearly written by AI (idk to which point with human intervention), so there are a lot of useless and incorrect things being done, some of which I pointed out in the review
2. Using esbuild as a bundler for development, which happens to be the same one ags uses, but that doesn't mean it will continue that way, specially the arguments used, which could mean different results in the final output and what a developer sees in development. It would be better to instead kill and invoke ags run . when a watched file has a change.
3. There already exists a pull request for this upstream in ags, which allows hot reloading. Maybe it's worth just building yourself that branch and using it (it's go, so building it should be quite straight forward) feat(cli): ags run naive --watch mode Aylur/ags#660

[davfsa]

Development vs Prod makes no sense for hyprpanel

[davfsa]

These comments are way too verbose and can be removed for the most part

[davfsa]

Running build with sudo is a big nono, there should be no need for this.

You can build and copy it to /tmp/ and then run it from there

[KernelDiego]

I have already made the requested changes. But I would like to clarify some things:

I just use esbuild, because in the documentation recommends that you can do the build with esbuild, and it is much faster than with meson.

On the other hand, the different results, I just configured esbuild to give exactly the same result, it does not change the name of the variables. There are two things that it does, the first one is to eliminate the code that is not being used, functions if used, etc, and the other one is for the reason that there is so much difference of weight in the final file (that is an improvement in time of initial load), is that meson leaves a source map inline coded in Base64 that weighs 2.8mb-2.9mb and it is one of the reasons why I did it in esbuild.

Besides, hotreloading is also faster because it only updates what has been changed using cache, which is more efficient.
On the other hand, doing a hotreload like the one shown in the pr you gave me in this project would not work. Since this project has script folders, style, assets, themes that need to be treated differently, and that's why the file is more complex than normal, and that's why I tried to document it, because it is optimized to only modify what is necessary, otherwise it would be super slow.

The development mode is to not overwrite the install directory when in development, as well as minify it in another way for debugging, as well as to quickly test between several branches.

Obviously you need permissions to install in the /usr folder, but I understand your point of not putting sudo directly.
Besides, the normal thing for development builds in ts/js projects is to do it in the root of the project such as build, dist, etc (as meson does by the way).

[davfsa]

I just use esbuild, because in the documentation recommends that you can do the build with esbuild, and it is much faster than with meson.

Just looked through both the Astal and AGS documentation and the only mention of it is a passing to inform that its being used under the hood, which is not something I (personally) would like to rely on.

Also, building using meson isnt the expected way to develop hyprpanel. You should instead use ags run .

On the other hand, the different results, I just configured esbuild to give exactly the same result, it does not change the name of the variables. There are two things that it does, the first one is to eliminate the code that is not being used, functions if used, etc, and the other one is for the reason that there is so much difference of weight in the final file (that is an improvement in time of initial load), is that meson leaves a source map inline coded in Base64 that weighs 2.8mb-2.9mb and it is one of the reasons why I did it in esbuild.

Thats a nice catch, but that should be changed in ags itself, not in hyprpanel. (Aylur/ags#708)

Besides, hotreloading is also faster because it only updates what has been changed using cache, which is more efficient.

The PR I linked does the same. Yours actually duplicates code quite a lot, since that cache will contain the same code as the src folder and will not facilitate incremental builds, as it will all need to be bundled together anyways. It is a bit wasteful.

On the other hand, doing a hotreload like the one shown in the pr you gave me in this project would not work. Since this project has script folders, style, assets, themes that need to be treated differently, and that's why the file is more complex than normal, and that's why I tried to document it, because it is optimized to only modify what is necessary, otherwise it would be super slow.

AGS is built around the the idea of a project like hyprpanel. It is aware of how to bundle and treat with scss files and the such (which hyprpanel utilizes a lot). Additionally, Hyprpanel has the builtin posibility to detect and hotload changes to scss and config files, so there is no need to add an external watcher on that to rebundle and restart the code, that would only need to be done for actual code.

If you want hot reloading, I would really recommend you downloading and building ags from the branch I mentioned (I use it localy and I know it works):

# Clone and checkout the branch
git clone https://github.com/Aylur/ags
cd ags
git fetch upstream pull/660/head:run-watch
git checkout run-watch

# Build it
go build

# Now you have a local `ags` executable that you can stick into your bin and use it
# You can then use `ags run . --watch` when you want hot reloads

The development mode is to not overwrite the install directory when in development, as well as minify it in another way for debugging, as well as to quickly test between several branches.

Nobody will be downloading hyprpanel from source to run it in "production mode" (as you say). If they do do it, the expected thing that they should do is bundle and build an executable, just like any package manager would do. This is inherently "complicated" and not wanted because that is not the ideal install method. Making it easier (or even possible at all) for this to happen at all during development by running the wrong command is a big no.

Obviously you need permissions to install in the /usr folder, but I understand your point of not putting sudo directly.
Besides, the normal thing for development builds in ts/js projects is to do it in the root of the project such as build, dist, etc (as meson does by the way).

My point was also that there should be no reason for commands that need root permissions to be part of a development command, specially given that hyprpanel is capable of running without any need for that.

---

Adding to all the above, after looking at the ags source code, the arguments you give to give to esbuild are not correct and will cause issues in the future (ie, you tell it the runtime is node, but that is not correct; you can find what ags passes here).

Overall, the two main points that this pr tries to add (watch and minifying the code) are better suited for ags instead. This PR adds a lot of complexity that hyprpanel shouldn't have to deal with

[KernelDiego]

Also, building using meson isnt the expected way to develop hyprpanel. You should instead use ags run.

ags run does exactly the same as meson (source map inline coded in Base64), that's why I did it with esbuild, which would be the lowest level, and again what Astal/AGS uses.

---

Thats a nice catch, but that should be changed in ags itself, not in hyprpanel.

It would just have to be seen if they accept the PR, because I see they are doing a V3 ags#685 v3

---

The PR I linked does the same. Yours actually duplicates code quite a lot, since that cache will contain the same code as the src folder and will not facilitate incremental builds, as it will all need to be bundled together anyways. It is a bit wasteful.

Again it is the normal thing when one compiles, not to aim to the source code. And for any environment where there is a compilation no matter how minimal it is, if you really want to test you should compile and have an environment with the same conditions as in the final version. And I think there is a misconception when mentioning the cache, when I refer to the cache, is that the esbuild itself that maintains an internal cache and knows when a file was modified, and he knows if he has to make an implementation or not, even if it is in a very large file, he is prepared to only write what is necessary, that's why it is so fast. With the rest of the files it is exactly the same (other than js/ts/jsx/tsx).

---

Nobody will be downloading hyprpanel from source to run it in "production mode" (as you say). If they do do it, the expected thing that they should do is bundle and build an executable, just like any package manager would do. This is inherently "complicated" and not wanted because that is not the ideal install method. Making it easier (or even possible at all) for this to happen at all during development by running the wrong command is a big no.

My idea was to directly replace the compilation method of both ags and meson, because of the details mentioned above, then, while maybe they did some migration with the documentation, etc; I decided to leave that flag depending on what they really want.

---

Adding to all the above, after looking at the ags source code, the arguments you give to give to esbuild are not correct and will cause issues in the future (ie, you tell it the runtime is node, but that is not correct.

Good point, the correct thing would be to use as runtime neutral.

---

Overall, the two main points that this pr tries to add (watch and minifying the code) are better suited for ags instead. This PR adds a lot of complexity that hyprpanel shouldn't have to deal with

Yes, especially because as I mentioned before I saw that they are working on ags-v3 where it already brings the implementation of watch the code. I will close the PR but I will make the corrections of the runtime, in case it is useful for another project or some implementation in the future and maybe it can be useful to someone.