Unified Plugin System，How to resolve plugin dependency conflicts?99% of the time is wasted on installing dependencies/various errors/various plugin dependency conflicts

### Feature Idea
Unified Plugin System，How to resolve plugin dependency conflicts?99% of the time is wasted on installing dependencies/various errors/various plugin dependency conflicts，

As a subject, the theme that various plug-ins rely on should require 80% of the dependency environment. It is very necessary. If the plug-in does not meet the requirements, you can ask to add dependencies yourself. For popular plug-ins with tens of thousands of downloads, 100% of the default dependency environment should be included.

There is no good way to solve the dependency conflict problem of a large number of plug-ins such as abcd--xyz. A requires plug-in 1, b requires plug-in 3, and c requires plug-in 4. There is no solution.

Unified requirements are necessary

Goals
Today, there are several different systems for extending ComfyUI, principally:

Custom nodes implemented in Python in the foldercustom_nodes
Custom javascript code in the folderweb/extensions
In many cases, a single extension will require both of these. For example, Davemane42's popular nodes require that files be inserted into both folders and be kept in sync. This makes installing and uninstalling the extension both difficult and error-prone.MultiAreaConditioning

I'd like to propose a unified plugin system that has the following goals:

Allow for plugins to be installed by simply dropping a folder into the folder (or checking out a git repository there)plugins
Allow for the future addition of additional extension points by both ComfyUI itself and other related tools (e.g. ComfyBox implementations of custom UIs)
Enable the creation of a plugin manager that can be used to install, uninstall, and update plugins without hard-coding all plugin information in the manager's repository.
Still allow for single-file plugins for the simple case (either a single python file or a single javascript file)
Proposal
Manifest
At this point, I think it makes sense to create a manifest file to describe a plugin. This manifest would simply be a file named in the root direcotry of the plugin. For the truly minimal case, only a name for the plugin would be required. (This would be used to solve conflicting node names as described in https://github.com/comfyanonymous/ComfyUI/issues/630.):manifest.json

{
"name": "Masquerade Nodes"
}
A full manifest might look like this:

{
"name": "Masquerade Nodes",
"version": "1.0.0",
"description": "Adds nodes related to masks",
"author": "BadCafeCode",
"update": "https://github.com/BadCafeCode/masquerade-nodes-comfyui.git",
"extensionPoints": {
"nodes": ".",
"web": "./web_extension"
}
}
Fields
name - The name of the plugin. This will be used to identify the plugin in the plugin manager and to resolve conflicts between node names.
version - The version of the plugin. This could be used by the plugin manager to determine if an update is available. (If we recommend that this be a semver, we could even perform automatic updates for minor patches/bug fixes.)
description - A description of the plugin (to be displayed by the plugin manager).
author - The author of the plugin.
update - A URL at which to pull new versions. For sources on Github (or other git repositories), the plugin manager could simply read the latest at the given URL to determine if an update is available. We could also add specific support for other sources (e.g. CivitAI).manifest.json
extensionPoints - A dictionary of extension points. While a limited number of extension points would be supported to start, other related tools (e.g. ComfyBox, CushyStudio, or ComfyUI-Manager) may want to have their own. For example, ComfyUI-Manager may want an extension point. This would allow plugins to include support for multiple tools without breaking compatibility with the default ComfyUI. The list of initial default extension points would just be: "install_script"
nodes - A path to a folder containing custom nodes or a single file. This would be used to replace the current folder. Defaults to if there are any .py files in the root directory of the plugin..pycustom_nodes"."
web - A path to a folder containing web extensions or a single file. This would be used to replace the current folder. Defaults to if there are any .js files in the root directory of the plugin..jsweb/extensions"."
Recommended Plugin Structure
While the manifest above is fairly flexible in terms of the structure of the plugin, I think it would be good to have a recommended 'best practice' that we encourage people to use. Honestly, I don't think it matters what that recommendation is as long as it's clear and consistent. My first inclination would be the following structure:

plugins/
my_plugin/
manifest.json
nodes/
__init__.py
my_plugin.py
web/
my_plugin.js
utils.js
Single File Plugins
@rvion brought up some good arguments for continuing to support single-line plugins, namely:

Self-contained examples to get people started
The ability to generate plugins via something like ChatGPT easily
To support those use-cases, any files directly in the directory would be treated as a plugin with a single extension point () and any files directly in the directory would be treated as a plugin with a single extension point (). Additional manifest information could be provided in a comment at the top of the file (starting within the first 3 lines):.pyplugins"nodes": "".jsplugins"web": ""

Python example:
'''
Manifest = {
"name": "My Standalone Plugin",
"version": "1.0.0",
}
'''
Javascript example:
/*
Manifest = {
"name": "My Standalone Plugin",
"version": "1.0.0",
}
*/
I don't think it's particularly important that single-file plugins support all functionality that normal plugins support (e.g. multiple extension points).

Workflow Save Changes
Along with this change, I'd like to see saved workflows (as well as those embedded in images) include the following information for used nodes so that the plugin manager can install any missing plugins with one click when importing a workflow:

{
"plugins": [
{
"name": "Masquerade Nodes",
"version": "0.0.9",
"update": "https://github.com/BadCafeCode/masquerade-nodes-comfyui.git",
},
{
"name": "WAS Node Suite",
"version": "1.0.0",
"update": "https://github.com/WASasquatch/was-node-suite-comfyui.git",
}
]
}
Outstanding Questions
Should dependencies be handled in the manifest? My first inclination is no since there are so many forms dependencies can take (installing Python packages, downloading models, etc.)
Should the list of provided nodes be defined in the manifest? This seems like a pain to maintain, but I think it would be really cool for ComfyUI-Manager to be able to add non-installed nodes to the node list with the ability to auto-install them when selected. For now I would lean towards not doing this, but it might be worth adding (as an optional field) in the future.
Should we be more prescriptive about the structure of the plugin? The current proposal allows the layout to be arbitrary as long as it's specified in the manifest. This makes it easier for existing plugins to migrate to the new system (since all they have to do is add a ), but it might be better in the long-term to have a pre-defined layout.manifest.json
Should ComfyUI have a plugin manager built-in? Probably not needed for the first implementation of this, but I do think it's something that should be considered eventually.

### Existing Solutions

_No response_

### Other

_No response_