Add plugins metadata to packages

[ma2ciek]

Provide a description of the task

Action items

• Move the current data from the OB and adjust to the new format - Move plugins metadata from OB to packages  #9400.
  • Make a final proposal for the metadata format and verify whether putting that into package.json is a good idea (taking into account that we'll have quite a lot of data there).
  • Check which plugins are not covered yet and if it makes sense, document them too.
    • One idea: PendingActions.
• Align the OB to these changes. -> Moved to OB issues.
  • The format itself changes and the data is split into two places (pkgs and OB's config).
  • It has to read SVGs source from npm pkgs.
  • We need to compile all this data and expose for the OB's frontend.
  • Consider writing a parser for build's default configs (builtinPlugins and defaultConfig).
• Document HTML output format For each major plugin specify the HTML output and add it to the package matadata #9401.
  • Try documenting a couple of features with the proposed HTML output format (or similar) and review whether the format makes sense
  • Make the final decision regarding the HTML output format and document all features.
• Document the format in the Framework docs (e.g. the "Contributing" section) and cross-link it at least at the end of "Creating a simple plugin" and maybe the tutorials - Document the metadata format #9413.
• Implement a generator for "Features output" documentation page. It will scan the metadata and try to print them out in a human-readable form in the docs - Implement a generator for "Features output" documentation page #9414.
• Notify WProofReader and MathType about the introduced metadata file -> Extracted as a follow-up.

[Reinmar]

Meeting notes:

• Data that we need
  • Plugins (in package.json, only the main plugins):
    • plugin name
    • human-readable plugin name
    • description
    • link to a feature guide
    • path to the plugin
    • additional toolbars
    • requires (soft and other weird requirements)
    • UI components:
      • name
      • path to SVG
      • type (button, dropdown, split button)
      • additional info (e.g. dropdown config - with or without text/icon?)
      • target toolbar
        • if defined, OB adds it automatically to this toolbar
        • if not, the user can
  • Online builder (separate, private config)
    • Plugins:
      • package.jsons of all pkgs and source SVG files
      • exclusions
        • what about exclusion groups? e.g. upload adapters
        • gets more complicated e.g. in case of RTE plugins
      • which sample
      • whether to show a certain plugin (e.g. Paragraph, Essentials)
      • "requiresServer"
      • private → premium
    • Default configuration of builds
      • duplicates the src/ckeditor.js file of each build
      • might be reasonable to write a parser to exclude builtinPlugins and defaultConfig
• Which plugins do we cover?
  • Only the glue code. No reason to cover *Editing, *UI
  • We need to cover soft-deps of other plugins (e.g. CloudServices)
• HTML output
  • To not repeat ourselves - plugins are configurable and so is their output. Also, plugins influence one another (e.g. alignment + block features).
  • Conclusions:
    • It'd be enough if CKE5 documented in its docs (in one place) all the possible outputs of all the features
    • CKE5 could try to standardize where this information can be written down by 3rd party plugin authors

[Reinmar]

The definition of HTML output could look a bit like this:

"ckeditor": {
    plugins: [
      { 
        name: "Alignment",
        output: [
          {
            "element": "$block",
            "attributes": [
              {
                "name": "style",
                "description": "For default config.",
                
                // Possible future extension - list values/particular styles
              },
              {
                "name": "class",
                "description": "For config.alignment.classes",
                
                // Possible future extension - list particular classes
              }
            ]
          }
        ]
      },
      { 
        name: "Image",
        output: [
          {
            "element": "figure",
            "attributes": [
              {
                "name": "class",
                "value": "image"
              }
            ]
          },
          {
            "element": "img",
            "attributes": [ "src", "srcset", "sizes" ]
          }
        ]
      },