Closed demize closed 2 years ago
I think you're correct, in that if there's no option specified, they'd be undefined; however, they won't be validated if they're not specified. The check for null is specifically meant to handle specifying null in the JSON, which is useful in some situations (in particular for my Docker container, which has to write out settings.json in its entirety, so being able to say it's null makes that curséd mess slightly less of one).
I'm used to typescript so I'm not super used to it, but couldn't you just not specify them for your container? Also, would probably be worth having an official docker file, if not a built image
I'm used to typescript so I'm not super used to it, but couldn't you just not specify them for your container?
The main issue (for me) is that it has to programatically build the settings file from the environment, which either means doing it as one cat <<- EOF
like I'm currently doing it or creating a series of ifs to check for each specific value. That aside, being able to explicitly set a value to null has value on its own for anyone editing a JSON file like this (especially since you can't have comments in JSON): if you're not sure whether you want to enable an optional setting or not, you can set it to null and then easily both a) know you meant to set it to null and b) edit it in the future.
Also, would probably be worth having an official docker file, if not a built image
I've got mine published on Docker Hub and the Dockerfile available on Github. If I'm going to maintain a Docker container myself, I might as well maintain it for the community too ;)
As is, settings.js crashes when trying to specify a level_timeout (as level_timeout is not present in the settings validations), and when a level_timeout is not specified the bot crashes when adding a level.
This PR addresses both those issues, as well as makes settings.js a bit more robust.