This has been on my mind lately. I’ve been using Node.js as my primary mode of TiddlyWiking for a little over a year, and keeping non-core plugins in the $_\plugins\
folder of each of my wikis seems to work best for me. Thought I’d share some of my thinking and usage in case anyone has thoughts (or wants to urge me to do things differently).
-
I’d already arrived at the method of having a master “TiddlyWarehouse” wiki where I keep all my globally deployed plugins and stylesheets. This wiki gets included in any other wikis I use or create, and I make any changes I want to see globally in this wiki. So I’m still able to benefit from updating plugins in one place, even though I’m not using an environment variable to point to a single \plugins
directory.
-
I keep my TiddlyWikis in a cloud-shared folder I access from multiple devices. By avoiding a central repository (that may live outside my cloud drive), I don’t have to worry about updating a master \plugins
folder on each local machine. I do have to make sure the TiddlyWiki version is consistent across locations and that my various tiddlywiki.info
files are up to date, but I have strategies for both of those things that have become habit and don’t create any friction for my workflow. (I know: I could use environment variables to point to the same cloud folder on each machine — but then I’d have to set those on each machine, and this way I don’t have to.)
-
There’s not as much consistency in the way users have organized their plugins as we might like. It can be a little time-consuming to figure out what should go in the plugin.info
file of a plugin I’ve never seen outside of a static TiddlyWiki — and I’m not 100% comfortable tearing up someone else’s plugin just to put it into Node folders. (I modify people’s plugins a lot, but I’m mostly able to do so by overriding their shadow tiddlers, making it easy to tell my changes from the original author’s work — and to toggle back to the original easily by deleting or renaming the tiddlers I’ve created.) Especially where there’s a chance an author will release a new version of a long-dormant plugin, prompting me to update, I like having the “unmolested” version of a single-tiddler plugin on hand.
-
For my own plugins, @PMario’s advice about using a \plugins
folder really resonates. But for those of you who do that in your development process, how do you make sure your constituent tiddlers get saved to the right path every time? Do you just keep good file path rules in $:/config/FileSystemPaths
and maintain consistent naming for your tiddlers?
I tend to have constituent tiddlers with names like:
$:\macros\secret-hq\...
$:\stylesheets\secret-hq\...
$:\skeletons\secret-hq\...
$:\images\secret-hq\...
-
$:\ui\secret-hq\...
… rather than $:\plugins\secret-hq\thisplugin\...
.
I organize them with a field that shares the same value across all the constituents, then use the Bundler plugin to gather and export them together as a .JSON file to generate my finale standalone plugin .tid
file.
Has anyone given thought to extending the functionality of drag-and-drop or plugin libraries to be friendlier to Node’s directory structure? Some sort of Node-based option to define a plugin directory in a configuration tiddler and then import anything that begins with $:\plugins\
to that folder, automating some of the messiness of creating a plugin.info from XML/values fields?
If that’s a bit of a nightmare to script — it may be a compelling reason for human TiddlyWiki users to forego their own version of that process when it comes to importing and refactoring existing tiddlers.
I don’t have strident feelings on this in any particular direction. Just wanted to share some of my feelings as an end user and tinkerer but not a heavy-lifting developer. If there are misconceptions anyone can correct, I’d love for someone to make the time and share. Or if anyone has grappled with the same questions, I’d love to know what conclusions you came to or where you thinking on this currently lies.