Installing Plugins on TIddlywiki + Node.JS: Help for Better Documentation

There is difficulty in installing plugins on Node.JS, specially for new comers! This wiki post is an invite for collecting comments/ideas/instructions for simpler installing and working with plugins on Tiddlywiki + Node.JS .

I have been using the below instruction. For example for new Section Editor Plugin

If still needs further help, then open another tiddler:

See the full doc here:

Section Editor — create, edit, fold, manage sections


I honestly think that for non-core plugins we should just tell users to install via drag and drop or via a plugin library.


I use the environment variables as discussed in: and point them to the plugin directories where I did download 3rd party plugins.

So every tiddlywiki instance will find them if I use the plugin in No need to add them to any wiki directory structure and updates will be global too.

I myself use this method! one other benefit is when updating Tiddlywiki (specially by downloading prerelease), your editions/plugins are there and working!

Why is there the difference between local and global layout? Any reason to not combine the patterns?

@pmario it looks like env paths want to have “global” layout i.e. includes publisher name?

It’s hard to contribute to a wiki that is all screenshots, but I think the “More on Client Server Installation” docs, after some tweaks for universality and grammar, would make a fine addition to

Mark, I have given link to GitHub and wiki page! See bottom of post above!

A local means it only works for one specific wiki!
Using ENV variable and putting plugin under tiddlywiki/plugins/publisher are both global!

I understand why there are two modes. So why use two different directory layouts? Can we change local to use the same publisher/plugin pattern?

This is what caused issues for me — I was running local mode but kept seeing docs for global mode.

I think you don’t need to add the plugin to the file if you install it locally (I never did that). So section III. Add plugin to file should be a sub-section of I. Global installation.

It only depends on your directory structure. … The publisher name is just a convention. In reality it is a subdirectory name. See: GitHub - wikilabs/plugins: TW5 plugins: … This path would be part of the environment variable. …

My plugins will be included with wikilabs/<plugin-name> … because the directory is named “wikilabs” … that’s it.

My relink env is: E:\git\tiddly\tw5-relink\plugins … the directory is relink only. So my looks as follows. … relink has no publisher prefix. … But for my own plugins I want to have them.

	"plugins": [

That’s true! good catch!

Right. But we can’t edit the wiki here to any effect. I guess if the document was changed to markdown, then everyone could edit. Then later it would have to be changed back. But of course some of the formatting would be lost going back and forth.

Here’s a tiddler with various grammatical and spelling fixes. I didn’t move the instructions on setting up because there are various ways to approach that. Personally, I would move it up under “global” as item 4.
more-info-on-nodejs-plugins.json (3.7 KB)



I just noticed that the part of the tiddler like this:

Here add <code><<shortName>></code>

produces a blank after “add”. I’m not sure what the intention was.

Edit 2:

Made a PR.

1 Like

Here are my suggestions, which I also posted in a Refnotes GitHub Issue (unfortunately also not editable):

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).

  1. 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.

  2. 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 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.)

  3. 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 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.

  4. 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 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.