Arguably, if I upload a compiled wasm I know what I’m doing and I don’t need handholding. That said, I see no issue with uploading the source map alongside the pre-built wasm if the script owner wants to have all the details.
We currently have error logs. If we expand that log to allow different levels, info , debug , trace , error , then that could cover it, right?
We don’t need all of that, we only need a facility to bubble up the messages to the script owner. A ring buffer of the last X messages that you can see is good (as long as I’m not forced to see all the source along with it over and over lol), roomscript log follow/unfollow to make logging interactive and message the owner immediately is even better. The specific naming and levels should not be part of the spec, IMO. I’d point you at some well-designed wasm interfaces again for the reference, but you have all the links 
Yes, we need a way to allow import of custom modules for boiler-plate code and class definitions.
This is going to be tricky. You’re effectively making an npm of wolfery with all the same issues that plague it. While I won’t say this is a wrong approach, I will say that it’s a monumental effort and you shouldn’t spend your time on it yet, because local-first tooling going to win anyway, because
I still think the easiest, and most valuable approach, is to improve the Mucklet Script dev environment, rather than focusing on in-client scripting UX.
Is pretty much correct. You can make a nice scripting environment inside wolfery, and ultimately it is a reasonable goal as it lowers the barrier for people to script things. At the same time, you are effectively building a mini-ide and a web-based compiler and package manager. It’s a lot of things for little gain. Instead, focus on the APIs. If you have a well-defined API to upload a script and tail the logs you can use it in a cli tool and in you potential future web editor.
I’ve seen the examples of both in the wild, especially around the crypto where people have to make good UX to keep on the hype. Given the current complexity of writing the room scripts I’d say the most important bit is to reduce friction. Here’s how you can reduce friction:
npm run publish is 10/10 problem solver because you don’t have to deal with the wolfery commands to reupload the code and it allows you to stay in your emacseditor of choicenpm run logs --follow allows you to keep on what’s happening with the script without having to fiddle between the char interaction and reading debug logs in the same browser tab
at that point, npm run publish-wasm that uploads the binary straight on will make things faster (because I already compiled the code locally anyway) and has all the benefits of pulling in external deps and doing the code splitting as you wish. It also allows you to write scripts in rust and that’s what we all here are after.
To sum it up: focus on the interfaces. You can figure the management APIs for cli and that tells you how to interact with them via an editor (even if that’s a standalone apieditor.wolfery.com). Let the developers write crazy things and come to you and tell you where your internal API is lacking and then you’ll know which internal bits to fix next.
And the wasm advice is still: think of your APIs as if you were writing them in C. If they are well-defined on the low level it’s easy to make bindings to the high level language, AS or whatever. You can automate most of that too. But if you think too high level then your API might be non-obvious (remember the chat where you explained me that init is called once in the script activation, not runtime? it’s confusing because that’s generally not how wasm modules are structured). I pointed you at proxy-wasm before, here’s the zellij plugin api which is also nice to work with. See how it’s structured. Events, commands and pipes are all similar to what you’re trying to do in here.
