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.

[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.

[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.

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.

How the example is related to the "plugin"? Why you need to know whether a plugin is written in wasm or not?

[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. xuri/excelize-wasm could render excel file in the web browser which used wasm.

How the example is related to the "plugin"? Why you need to know whether a plugin is written in wasm or not?

The wasm example just show the possibility to convert legacy render code as a js plugin via wasm. I can remove the example if it's unnecessary.

[silverwind]

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.

But then you are forcing plugin authors to maintain 2 metadata files. package.json is well-defined standard for JS packages and plugins are JS packages.

package.json has flexible logic on how a package entry point is specified. I'm not saying we have to implement all the complex mechanisms, just the basic ones like exports used with a string. Here for example a basic plugin:

package.json

{
  "name": "helloworld",
  "type": "module",
  "exports": "./index.js",
}

index.js

export const render = () => "hello world";

[lunny]

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.

But then you are forcing plugin authors to maintain 2 metadata files. package.json is well-defined standard for JS packages and plugins are JS packages.

package.json has flexible logic on how a package entry point is specified. I'm not saying we have to implement all the complex mechanisms, just the basic ones. Here for example a basic plugin:

package.json

{
  "name": "helloworld",
  "type": "module",
  "exports": "./index.js",
}

index.js

export const render = () => "hello world";

See nodejs.org/api/packages.html for good documentation on what a JS package is.

But wouldn’t that force users to depend on Node.js? Some users may prefer developing plugins using other ecosystems or languages. Many platforms—such as Chrome—provide a metadata file format that does not require Node.js at all.

[silverwind]

No, Node.js is not required at all, your plugin loader takes the role of Node.js and is responsible for loading the module by first parsing package.json, determining the entry point, creating a URL to it and then load each plugin similar to this:

const {render} = await import(pluginUrl);
const element = document.querySelectorAll(".render-target");
await render(elements, data);

[silverwind]

The main benefit plugins being npm packages that they can be published to npm and sourced from there. Of course to directly install npm packages directly from the npm registry, a JS package manager like npm, pnpm or bun will be required to download the package.

Packages sourced from a local directory may not require a package manager, but in practice they might as well do because many of them will need other npm dependencies to render content.

[silverwind]

Also to note, I guess any sufficiently complex render plugin will want to bundle and minify their code (with a bundler like https://github.com/rolldown/tsdown), so their entry point may for example be a ./dist/index.js. Still a possible with npm packages and many do publish bundled code to the npm registry.