Feature request: allow an external config override globally

[Marnek]

Hello,

this should be fairly easy to implement and would help deployments in homelab settings be more configurable than the standard "run-as-is" code..

Basically, people who run Snapdrop in private LANs with no security concerns would be able to change settings that are not production safe, either for testing purposes or to improve their Snapdrop experience.

The way I'm running Snapdrop is via a container, with the /config being a bindmount, but there's not much to modify in that folder. Not great, considering that is the only "static" path across container upgrades.
I've been modifying code inside the container itself in the past and it was wiped on container upgrades, as expected, needing manual editing from me repeatedly.

I know the simple solution to this is to not pull a newer image, however I want to keep up with the feature set and any improvements that are done, so it's a no-go

What I have been doing recently to "stick" changes as much as possible is migrate any important variables or settings in a file /config/custom.js (locked across image pulls) and reference it in the /app/www/server/index.js to reduce the amount of code I have to replace. Here's an example, not something important, but should get the point across:

# /config/custom.js
var deviceName = "new-naming-format";

// Export the modified deviceName
module.exports = {
    deviceName
};

---

# /app/www/server/index.js 
const customCfg = require('/config/custom.js');

[...]

const displayName = customCfg.deviceName  + ' #' + this.id.hashCode();

This works and reduces the workload when a new image is available, but it's still not as good as it can be.

Why not, by default, let Snapdrop check for the presence of a "custom.js" file? Then just branch the way variables are referenced:

Case 1 - custom.js doesn't exist/is empty -> reference the variables the way they are now (run 'factory Snapdrop')
Case 2 - custom.js exists + all customizable variables in it are populated -> switch referencing of variables in main code to customCfg.variable_name
Case 2.1 or 3 - custom.js exists + some customizable variables are populated, others are not or NULL -> switch referencing of variables in main code to customCfg.variable_name where possible, default to factory code referencing where not..

What do you think? It shouldn't be a major code overhaul, and any existing variables that can improve experience/functionality can be migrated from the main code to custom.js and reference them without major rewrites. If this is done, any new code pulls won't break things as your custom.js stays the same :)

Looking forward to your input and suggestions