power-mailinabox
power-mailinabox copied to clipboard
Feature Idea | Adding Admin-UI from badsyntax
I know power-mailinabox did already quite some improvements to the UI compared to the standard mailinabox ui, but I stumbled uppon this admin-ui improvement from @badsyntax and thought, it might be a cool feature to implement to power-mailinabox (if possible)
https://github.com/badsyntax/mailinabox-ui
Hi! I am aware that badsyntax's UI is awesome, having myself tried it out - unfortunately, without it's own drawbacks:
- Files need to be prepared for web usage: Web browsers cannot run TypeScript directly, as such it's not a drop-in solution. Ways to integrate the UI from the top of my head include:
-
- Install nodejs on the user's machines and have it run the server for the UI. This means that there will be two daemons now - one for the UI, another one for the backend. The bad thing here is that the node server can take quite a bit to start, as such the admin panel will take a while until it is available for use;
-
- Add a build step on installation-time where the UI files are built (into JS files). This is slightly better as we're recompiling less, but we're still installing nodejs and downloading tons of files to feed
node_modules;
- Add a build step on installation-time where the UI files are built (into JS files). This is slightly better as we're recompiling less, but we're still installing nodejs and downloading tons of files to feed
-
- Add the build step via GitHub actions and the setup script downloads the compiled files - better, but will take a lot of effort to set up the infraestructure to do so;
- The UI is not fit to Power Mail-in-a-Box in the sense that Power-MIAB has more features than the UI exposes (SMTP Relays, PGP keys, etc. are not present in the UI) - unless anyone is willing to do the respective adaptations it's not even useful for us;
Bottom line, it doesn't look like something feasible to integrate, at least not right now.
I'm not pushing you to use it, in fact it was just a proof of concept and opportunity to upskill on Typescript and react.
I will however say I'm rather confused by your points. If you use any form of modern JavaScript a build step will be required to compile/transpile the JavaScript to an older version of JavaScript that will run on older browsers. The build step should have nothing to do with users/consumers of the code. The users only consume the built files. I don't see your first two point as actual options.
I'm not familiar with how MiaB is deployed but I assume it's just a "git pull", in which case just commit the built files to the repo, this will be the easiest approach. Alternatively you can publish the built files as release artifacts. When you update MiaB on users machines it pulls down the built files from the release artifacts. Agreed this is extra effort but it's not a ton of work. Just my 2 cents.
The users only consume the built files. I don't see your first two point as actual options.
This is correct - if the box is not very well provisioned adding a build step will extend the setup time quite a bit, and it's not my goal to raise the system requirements :sweat_smile:
I'm not familiar with how MiaB is deployed but I assume it's just a "git pull", in which case just commit the built files to the repo
Yes for the git pull, but committing the built files to the repo is a big no-no. That's equivalent to committing the node_modules folder, or committing binary files to the repo (.exe, .dll, .so, etc.).
Creating artifacts to upload on the Releases page is a better approach from a user-standpoint, and if we want to be git-pure the theoretically best approach is to actually keep the admin UI repo separate from the main repo, but that is an awkward approach from a developer perspective, because now you have effectively two repositories to maintain.
And what if we don't need the git-pureness? Just copy paste your files, remove the old UI, one big commit, we're done :D Until the upstream project changes the admin UI and now you may or may not have weird merge conflicts.
Bottom line, the issue in here is that we need to make compromises from a developer/maintainer perspective. Definitely possible to happen, but there might be a better way than the approaches I just laid out here.