When making more complicated commands using eval, I often have to alias one command to another to get around nightbot’s limits. Assuming those limits won’t be raised (notably the 500-char size limit and the variable expansion depth), it would be extremely useful to me if I could do two things:
Set commands to only be allowed to be used, if called from another command. For example if I make a command ‘!actual’ that does some work, and then another ‘!alias’ that aliases !actual and provides input, I would set ‘!actual’ to be alias-only so that I can’t call !actual from chat, but only !alias.
Hide commands from the commands list. Possibly as an extension of the above, to keep people from trying to use those commands it would be nice if I could hide commands from the publicly-available list of commands on the website. It would make sense to me to hide alias-only commands.
I don’t think we will raise the character limit for normal commands, but I’m interested to hear your use case involving using aliases in this manner. Perhaps we can change the product to account for it. Can you elaborate more?
I run into both those limitations with some regularity, though the character limit is generally a bit less imposing than the variable expansion depth.
The command I was making that prompted me to ask for alias-only commands is currently a 494-character eval script (counting $(eval)) that I had to really put through the wringer to fit inside the 500-character limit. Think remove every single non-string space, single-character variable and function names, exclusively arrow functions, even renaming Math.floor() to just f() since it’s used twice. And in fact it isn’t enough, because the last thing it does to actually return the response is effectively something like $(eval $(1)($(2))), and then a second command (which is actually the one called from chat) fills in $(1) and $(2) according to what the chatter wants, i.e. it directly calls a function that is defined earlier in the eval.
This is mostly fine if the aliased-to command can’t be run directly, but if it can one could put something else there and it’d be executed as a function. In general $(eval) scripts are often vulnerable to script injection but here it’s literally what I had to do to make it fit.
Having longer character limits (which I understand can’t be unlimited) and deeper variable expansion would allow me to both put most of my commands that are now implemented as two commands, one aliasing another, as a single command and it would allow me to do better input validation which requires both deeper variable expansion (think $(eval $(urlfetch url-dot-com/foo?$(querystring $(1)))) and more characters.
Another issue with this is that I can use the $(twitch) variable to determine if a user exists, but that variable turns into something like “Unknown Twitch User” which makes it harder to use as an aliased command argument because now rather than just $(touser) it’s suddenly three separate arguments because of the spaces.
By the way I’m incredibly appreciative that Nightbot even offers a way to run custom code; I can’t do most of the stuff I’m doing with any of the other cloud bots. So thank you for that.
While I’m happy that eval somewhat works for your use case, it is mostly built for simple commands. It sounds like you need something more like ability to run an entire script for a command rather than a snippet. It’s not something we support right now but is an interesting idea. I’ll toy with some ideas when I get the chance and see if there’s something that can be built. In the meantime, you might consider using something like Cloudflare workers with urlfetch to get added flexibility without jank implementations.
Eval itself actually works very well. It can be a bit tricky to get started with (given the limited error reporting inherent to such a system) but once you have a handle on how to develop these scripts, it means Nightbot can do almost anything.
The limitations I’m running into are in fact outside of eval; it’s just that my use of eval makes them apparent.
I actually do something like that as well (albeit either with google cloud functions, which is the same idea, or just a server that I own sometimes), but nightbot’s eval allows me to do things without setting up infrastructure, which means I have fewer moving parts to maintain.
This still has the variable expansion depth problem though, unless I forego eval entirely. But in those cases I use eval combined with urlfetch returning a json for error handling. For example I have a shoutout command that queries a GCF which itself pulls data from a google sheet so we can tailor the shoutout to the person being shouted out. This can fail in a number of ways, and using eval combined with urlfetch json I can detect those and respond with a generic shoutout instead of an error message.