Plugin design: splitting up vs. duplicating

[HC Haase]

In developing my plugin I can see a couple of features could be usefull as seperate plugins of there own.

I wonder what would  be best practice

1. To keep everything in one plugin
   self contained, easy to install, but only on plugin. However, if functions are copied to another plugin later, this would take more space. It could also complicate things if two plugins edit the same shadow tiddler.

2. Make a main plugin with dependencies on smaller plugins
  This would give several different plugins but would be more cumbersome to install and to maintain. And it could be a mess in the future, if by mistake, a plugin update will break a dependency.

And what if you use something from a plugin from someone else? E.g. a background from shiraz. Then you have no control over future updates. Would it then be best to copy the function from the plugin to your own or to make a dependency?

[TonyM]

HC,

This is a very good Question. I think whilst coding can be a science sometime it becomes an art. Here are a few thoughts that may guide the decision

• Do the various features of the belong as one logical unit?
• This seems so when there are dependencies
• Are the features valuable stand alone?
• Weather or not to package has a lot to do with the total size of the package, 
• if small, package then if you can name that package in a way, that the name for the package suggest whats is in the package
• Increasingly others are looking to bundle via a library, this may be a way of not having to choose;
• Divide them into standalone components that can work together, bundle them in a library.
• Design to avoid shared tiddlers etc... however if it is :necessary: you can code checks and balances in each plugin.
• For basic features try and write your equivalent function such as css rather than depend on a broader solution such as Shiraz
• When you need a lot of the third party plugin perhaps make it a dependency.
• Given the broad licensing in many cases you could provide a link to the other parties code or even bundle it with your package (as an option, although a frozen version)
•  Consider a solution that works but omits a feature unless an additional feature is installed, including whether a third party plugin is installed.
  
• You can test for the existence even enable/disable state of plugins and packages

Just some thoughts

Tony

[HC Haase]

Thank you for your thoughts. it is good to get some other persepctives.

as I feard, this is not a clean cut.

[bimlas]

HCHaase,

Tiddly handles plugin dependencies well, so I would vote for separate plugins in this regard.

https://tiddlywiki.com/#Plugin%20Dependencies

If we look at how NPM (Node.js Package Manager) works, it is entirely made up of package dependencies: each package does one single thing (in principle).

On the other hand, if I want to install a plugin for a "ready-made program" (Vim, TiddlyWiki, VSCode, etc.), it's a bit daunting if the plugin wants to install additional plugins. From a user’s point of view, technically, there’s really not much difference between installing a single plugin and installing multiple plugins because they take up the same amount of space. The real difference is more psychological, so whether the user accepts having to install multiple packages at once. If a plugin is used by several other plugins, it actually saves space because you only have to install that sub-plugin once, but the average user will not see this.

We have to think instead of the user and make the right decision, so I will vote for the multiple plugins. Copying is never good, because if you find a bug in one place that you fix, you have to keep it in sync to be fixed in the other places when you make "monolithic plugins."

[PMario]

Hi,

I think, it depends on how "connected" your plugins are. If 1 functionality is hardly used without the other, I would keep it in 1 plugin.

If it is very likely, that they are useful alone, and do completely different things, you should split them. The chance is high, that users demand different new "features". So the code base can't be shared after a view iterations anyway.

If they share eg: 40% or more code, I'd go with 1 plugin, until it really needs to be split into a "main" and "feature" plugins. ... But I think you can go a long way here. IMO up to 30k in plugin size, uncompressed, before you start splitting. ...

I think at the beginning its relatively hard to know, the structure, that will be really needed. So after some time a module like rewrite may be a possibility.

Splitting will be made easier, if you keep it in mind early and already start with a module like structure.

You can have a look at the tw core, how "modules" are created. Have a look, how the module-type field is handled, if you are interested.

just some thoughts.

-mario