At minimum, having apt, nano, curl, and ssh installed is pretty much a no brainer. But you don’t need the dev tools, you don’t need the docker runtime or VMs, you don’t need a graphical environment (many choices, none perfect), but you do need the basic bash scripting tools.
My current philosophy for Tiddlywiki is “if you can do it with a plugin, do it”. Core doesn’t really need more user comforts but extensibility is an ever expanding work in progress. There are certain features that I always add to every single wiki, like certain macros that I find useful, and if you find yourself always doing that, that can indicate it’s a feature that could be useful in core. Macros and small style tweaks are especially good candidates for that. Also, if you’re good at coloring a UI, palettes need more diversity. If someone makes a really good theme that answers ALL the scenarios perfectly, that would be a candidate for an official plugin.
This is something that I’ve related to a lot in working with TiddlyWiki. I made TiddlyServer, for instance, (https://arlen22.github.io/tiddlyserver/), and I made it entirely based on code that was already existing in TW5, mostly just using standard features in boot and core. The core is intentionally built to be extended, and it was the core code that actually gave me the idea for how to write TiddlyServer. I didn’t come up with it, I just saw the pattern and used it.
That being said, the thing I have made more pull requests for than anything else is the boot folder loading code. After four or five different PRs trying different ways of approaching the situation, I finally came up with the rather simple solution of dividing the startup function out into three separate functions which would allow the init and exec portions to remain the same while being able to change the load portion to use async calls. That PR was accepted and I can now happily override the data loading with any async adapter I want without worrying about maintaining the init and exec portions every time they change. The main use case for this would be “TW5 in the cloud” and other “NodeJS TiddlyWiki5” scenarios where blocking is undesirable or impossible.
https://github.com/Jermolene/TiddlyWiki5/blob/master/boot/boot.js#L2491-L2497
$tw.boot.startup = function(options){
options = options || {}; // Get the URL hash and check for safe mode $tw.boot.initStartup(options); $tw.boot.loadStartup(options); $tw.boot.execStartup(options); };
So my two cents is: do what you can as a plugin, and think of the most generic and useful ways to make improvements to core that retain existing compatibility and keep things organized and performant.
