Do not merge/js doc

[petermuessig]

[petermuessig]

@thodd :

this morning I discussed with @codeworrior to not patch the api.json and rather create a api-mixin[-xxx].json next to the api.json which can be collected by the jsdoc generation to patch the apis.json with the provided content. Then we can prepare this during the regular build in our existing task and just drop it into the test-resources/%namespace%/designtime location.

[Thodd]

Meeting notes

JSDoc / api.json

Mixin

• How to prevent reimplementation of getter/setter definitions?

  • We don't want to duplicate generic code from the JSDoc plugin

• Wrapper contains JSDoc comments

  • Pro: Easier regarding api.json genration
  • Con: Rollup might not be able to decouple wrapper modules
    • Idea: If this is true, can we just remove the other comments except for the control wrapper?
    • Questions:
      • Can we guarantee that each control wrapper is contained in a separate module?

• What is considered public/exposed in a lib?

  • Are dependent (seamless) control wrappers public?
    • e.g. the base class
      • This means the api info must contain the full hierachy
    • What about other related entities, e.g. aggregation types, enums, ...?
      • do they need to be contained in the api.json?
  • Or only the dedicated wrappers?
    • This means we must flatten the API info
    • But what about the related entities?
      • they must also be exposed as a dedicated wrapper

[petermuessig]

Closed in favor of #1171