Plugin Finding -- can they broadcast their existence?

[TiddlyTweeter]

I find the finding of plugins that have essential utility very laborious.

Is there not a way that when its created a plugin can BROADCAST its existence to a central repository? Are we so distributed we can't find a decent centralised solution?

My focus here is on getting TW used more. Much of its utility is revealed most via plugins. Currently finding them is a huge mess. Its consequently v. hard, particularly for beginners, to find functional solutions that plugins deliver.

This is damaging TW's uptake imo.

[sukima]

There was talk at about moving plugin's into NPM modules. By doing so TW plugins can easily be discovered through NPM.

[TiddlyTweeter]

Ciao @sukima would that mean you'd need be on node?

A recent effort by David Gifford to list TW resources, mainly plugins ... https://dynalist.io/d/zUP-nIWu2FFoXH-oM7L7d9DM ... I think illustrates the issue that is escaping solution. Its been started before on Reddit by Riz ... https://www.reddit.com/r/TiddlyWiki5/wiki/pluginsandresources. And Erwan's (good but very underused) aggregator ... http://erwanm.github.io/tw-community-search/#CommunityAuthors:CommunityAuthors underlines it.

Problem is we have zillions of good plugins (and likely some bad ones) all in a lost forest. Many developed outside any shared framework. Simply as TW. No shared code base. Just individuals having great ideas.

I'm not god. And I'm not a programmer either. I'm not sure what a decent solution could look like.

But I AM clear that the way that major additions to TW by independent coders currently works often makes it hard for their work to find its lasting place.

Overall, I think its damaging TW in two ways:

• Beginners find it very difficult to find solutions because there is very poor indexing of what is;

• Its (in a way) disrespectful to the plugin makers--they left to the entirely arbitrary Darwinism of the Google Group whether 1 or 50 read them on the day of launch.

I'm sure we can do better. But I can't see quite how without some method to automatically aggregate?

[sukima]

would that mean you'd need be on node?

Not necessarily. My comment was in reference to establishing a package idiom all plugins follow. NPM offers this out of the box. There for is you run TW in node you gain the advantage of npm install --save my-awesome-plugin but if you use just the HTML version then you simply head over to npmjs.com and search for some established keyword like tw-plugin.

Ultimately we need a package manager. whether that is home grown or a different tool. My personal opinion is to use the resources already available and let NPM do the package management.

[danielo515]

I was the one that proposed to use NPM for plugin distribution, and I still think it is a great idea. If you are using the node version, or compiling a TW from node, or you build automatically any TW on Travis (like my tutorial/template of automatic TW on github pages) you just have all this for free. For those using the browser we can build a small server-less architecture that serves the plugin the TW plugin library asks for. Many server-less providers offer reasonable free tiers, so this can come also for free.

[TiddlyTweeter]

If a developer who was simply using their browser to develop plugins could also get it known this way, without too much effort, it could work. One thing clear to me is that the current way we publish add-ons is a mess and its counter-productive. It should be advancing TW & it isn't.

[danielo515]

There are some devs. building plugins on the browser , Ok, they are crazy enough. I don't see how making this available first to node ones can hurt in any way

[linonetwo]

I'm going to implement this in TiddlyGit, I will use npm package to programmatically install npm package that contains tiddlywiki plugin into a temp dir, and then copy npm package's plugin folder into the wiki's plugin.

I suggest using "tiddlywiki-plugin" as a pointer field, just like how "main" and "typings" works:

  "main": "index.js",
  "typings": "threads-plugin.d.ts",

[linonetwo]

And, use keyword: ['tiddlywiki'], allows me to search for available plugin list to install.

On, I will talk about this in https://github.com/Jermolene/TiddlyWiki5/issues/2817

[danielo515]

That sounds amazing @linonetwo

[pmario]

Why don't we use the existing mechanism?

TW has a plugin mechanism to load plugins into an existing wiki. You only need to import a tiddler, that contains the link to the plugin library and some meta data.

title: $:/config/wikilabs/PluginLibraryWL/latest
tags: $:/tags/PluginLibrary
caption: Wikilabs Library (latest)
url: https://wikilabs.github.io/editions/pluginlibraryWL/library/latest/index.html

~WikiLabs plugin library latest version!

If this tiddler is part of a wiki the built in plugin mechanism works flawlessly.

[natecain]

It seems worth pointing out that TW already has existing support for treating module tiddlers as CommonJS (NPM, etc) modules. There are even (hopefully still passing?) unit tests to assert that we conform to the standard.

Building on this CommonJS support, in order to support NPM's package.json format, and even for fetching/loading packages with dependencies, should all be fairly straightforward.

On Thu, Jun 3, 2021 at 3:01 PM Mario Pietsch @.***> wrote:

Why don't we use the existing mechanism?

TW has a plugin mechanism to load plugins into an existing wiki. You only need to import a tiddler, that contains the link to the plugin library and some meta data.

title: $:/config/wikilabs/PluginLibraryWL/latest tags: $:/tags/PluginLibrary caption: Wikilabs Library (latest) url: https://wikilabs.github.io/editions/pluginlibraryWL/library/latest/index.html

~WikiLabs plugin library latest version!

If this tiddler is part of a wiki the built in plugin mechanism works flawlessly.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Jermolene/TiddlyWiki5/issues/3102#issuecomment-854104795, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADULMIUMT4CZYK6SLFVFXTTQ7GQJANCNFSM4ENN3T4A .

[linonetwo]

@pmario By using the current plugin library, the plugin will result in a .JSON file, not a folder in the nodejs wiki's plugin folder. I just want a way that works like the plugin library , but will put things into the plugin folder.

And by using a plugin library, there is no a central library , which will result in lots of libraries created, become a mess for users to maintain. But github or npm can be a unified central library I think. The best result can be that @Jermolene creates a GitHub repo that allows everyone to put their plugins, and build as a big central library.

[linonetwo]

@natecain do you mean tiddlywiki can somehow read node_modules? I don't really get it, is there any example?

[pmario]

... The best result can be that @Jermolene creates a GitHub repo that allows everyone to put their plugins, and build as a big central library.

There can be a central repository that holds links to plugin libraries. I want to be able to plublish my plugins at any times, without any delay.

Such a "link-register" could also have an optional SHA256, so users can verify, that the library they import hasn't been modified. .. IMO this would increase the TW security a little bit. ...

We don't have any way to verify our libraries at all.

[linonetwo]

The drawback of links to plugin libraries, is that you can't easily search for plugin, if you didn't install the library. And nodeJS wiki can't save plugin to the plugin folder now, which is a drawback too.

I think if use Github repo to publish plugin, you can plublish your plugins at any times, you can just put them in your own repos ,and let Github index them for searcher.

[natecain]

No, as the name implies - node_modules is something NodeJS specific. It is not a part of CommonJS Modules. (Node implements and extends CommonJS. All Node modules are also CommonJS modules but not all CommonJS modules are Node modules...)

Examples can be seen in the unit tests at https://github.com/Jermolene/TiddlyWiki5/tree/master/editions/testcommonjs/tiddlers

These correspond to the CommonJS Modules/1.0 unit tests at https://github.com/commonjs/commonjs/tree/master/tests/modules/1.0

The specification details can be found at http://wiki.commonjs.org/wiki/Modules/1.0

On Fri, Jun 4, 2021 at 3:17 AM lin onetwo @.***> wrote:

@natecain https://github.com/natecain do you mean tiddlywiki can somehow read node_modules? I don't really get it, is there any example?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Jermolene/TiddlyWiki5/issues/3102#issuecomment-854426211, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADULMIG5DT5QARTFWGXPPTTRB4XPANCNFSM4ENN3T4A .

[natecain]

Sorry, upon double-checking I realized that we actually implement the v1.1 spec at http://wiki.commonjs.org/wiki/Modules/1.1

On Thu, Jul 1, 2021 at 2:53 PM Nathan Cain @.***> wrote:

No, as the name implies - node_modules is something NodeJS specific. It is not a part of CommonJS Modules. (Node implements and extends CommonJS. All Node modules are also CommonJS modules but not all CommonJS modules are Node modules...)

Examples can be seen in the unit tests at https://github.com/Jermolene/TiddlyWiki5/tree/master/editions/testcommonjs/tiddlers

These correspond to the CommonJS Modules/1.0 unit tests at https://github.com/commonjs/commonjs/tree/master/tests/modules/1.0

The specification details can be found at http://wiki.commonjs.org/wiki/Modules/1.0

On Fri, Jun 4, 2021 at 3:17 AM lin onetwo @.***> wrote:

@natecain https://github.com/natecain do you mean tiddlywiki can somehow read node_modules? I don't really get it, is there any example?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Jermolene/TiddlyWiki5/issues/3102#issuecomment-854426211, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADULMIG5DT5QARTFWGXPPTTRB4XPANCNFSM4ENN3T4A .