Feature/PluginSystem

[matthias]

In this PR I propose a Plugin & hook system for Flowise

Plugins are packages, that currently live in /plugins - but they should also be installable via npm

It borrows ideas from the WordPress plugin and hook system. One of the most powerful forces why WordPress became such a popular OpenSource framework (despite a lot of not so likable things about WordPress code)

Within a plugin package we use package.json/main to point to the plugins main class which extends the FlowisePlugin class

It automatically loads components and credentials from the plugins directory by specifying nodesPath and credentialsPath

=> Check the components in the UI within a new "Custom" section

Under the hood it's using an event based hook system (based on EventEmitter) that adds the ability to collect and manipulate (filter) data, via emitting and listening to events (we call them hooks)

p.s.
Some changes where introduced by yarn lint-fix
p.p.s.
Sorry for the first broken commit/pr - pls ignore / delete

[HenryHengZJ]

hey @matthias thanks a lot for the initiative! Am wondering whats the difference between plugin vs users creating their own node in packages/components/nodes?

[matthias]

hey @HenryHengZJ - thanks for looking into this.

I think it's the much cleaner separation than working directly in the same folder / code structure as the core project.

I thought about it since I'm working with Flowise. Coming from WordPress I was wondering why it's not more common to have a plugin/hook architecture in Node/JS projects. Then I investigated deeper into langchain recently - and discovered that they provide a mechanism to have custom nodes in a separate folder - which I liked very much. I elaborated this idea, because I could imagine that from a certain point you don't want to have 100th of nodes in the core / UI - but rather be able to install additional "packages" of functionality (not just nodes)

Currently it needs a very deep dive into the code until you know where to add what - and there is the constant need of updating and merging code bases. Adding own features by forking is possible, but I would rather not do it in the long run as it constantly requires to keep up with all the codebase (as you never know what could change) - and solve merging conflicts.

Actually adding / loading nodes from a plugin was just a demo use case of the hooks. They (hooks) are the important part, as they allow Flowise to add clear entry points how to add things. This could also be additional navigation points or more down the road.

Imagine other use cases, as adding / managing / observing sources. Adding alternative chat UIs. Adding api endpoints (routes).

Could be interesting for custom(er) projects based on Flowise. But could also be a mechanism to develop new features, before they become part of the core.

[HenryHengZJ]

ah perfect got it. I'm really excited bout this! In the other words, these are nodes that community created and are seperated from the official nodes. Owner can maintain/upgrade the node, and community can install and reuse them.

will cleanup some code and see how to have a nice UI to display plugins