Add frontend render plugin system support

[lunny]

Resolve #34917

• Render plugins list

• Render plugin view

• Render plugin example

• Render wasm plugin example

[wxiaoguang]

Don't understand why wasm is introduced and becomes a must.

It's highly likely a wrong design: when you have a hammer, then everything in your eyes become nails.

[silverwind]

I'm still of the opinion that plugins should be npm packages with a package.json that declares their metadata and dependencies. I don't think it's good to create a new manifest.json file format when the package.json format already has most of what you need.

The big benefit of being a npm package is that these plugins can be puplished to the npm registry so be installed from there or a local folder.

Take for example VSCode extensions, those are also npm packages at their core, with additional package.json properties specific to extensions.

[silverwind]

Don't understand why wasm is introduced and becomes a must.

WASM support is nice, but it should not be required. The entry point to a plugin should be JS function, and whether the plugin than loads a WASM module or not is the plugin's decision.

[wxiaoguang]

I'm still of the opinion that plugins should be npm packages with a package.json that declares their metadata and dependencies.

• [Propsal] Dynamical Frontend Render Plugin #34917 (comment)

  Well, every time I say "it would cause problems", then it really causes problems.

---

Don't understand why wasm is introduced and becomes a must.

WASM support is nice, but it should not be required. The entry point to a plugin should be JS function, and whether the plugin than loads a WASM module or not is the plugin's decision.

WASM is definitely a new abuse here, unless it could prove that it brings real benefits.

[lunny]

Don't understand why wasm is introduced and becomes a must.

It's highly likely a wrong design: when you have a hammer, then everything in your eyes become nails.

It's just an example. There is no special code to support wasm. It's a nature support from web browser. The benefit of wasm could allow render plugin reuse the legacy code written by other lanuages. i.e. https://github.com/xuri/excelize-wasm could render excel file in the web browser which used wasm.

[hiifong]

Perhaps Obsidian's plugin solution will be helpful to us: https://docs.obsidian.md/Plugins/Getting+started/Build+a+plugin

[lunny]

Don't understand why wasm is introduced and becomes a must.

WASM support is nice, but it should not be required. The entry point to a plugin should be JS function, and whether the plugin than loads a WASM module or not is the plugin's decision.

Use a file name as entry is commonly and useful.

I'm still of the opinion that plugins should be npm packages with a package.json that declares their metadata and dependencies. I don't think it's good to create a new manifest.json file format when the package.json format already has most of what you need.

The big benefit of being a npm package is that these plugins can be puplished to the npm registry so be installed from there or a local folder.

Take for example VSCode extensions, those are also npm packages at their core, with additional package.json properties specific to extensions.

The package.json file could be in the repository of the plugin repository, but for the final dist or zip file, we don't need the extra information in the package.json. That means the manifest.json is for the runtime and package.json is for the development and I don't think the npm ecosystem could not be reused.