Add support for custom data

Salesforce is quite interested in capitalizing on a manifest like this for a range of projects. I believe the proposed state of schema.ts already covers the majority of Salesforce’s requirements. The remaining requirements are rather proprietary, and could be addressed with general-purpose mechanism for including custom data in a manifest.

This could be achieved by:

1. Adding a standard, unrestricted custom key to the top-level schema.
2. Recommending a strategy for component authors or tool vendors to further subdivide that custom key. Example: an organization adding custom data should do so inside a key containing a relevant domain name they own.
3. Encouraging tools to either ignore custom keys they don’t understand, or to perform generic processing of anything they find there. Type-checkers could potentially ignore all that data. A doc tool could either skip the custom data, or format it as a pretty-printed JSON block or table as supplementary documentation.

Example: Using some hypothetical custom data values taken from Salesforce’s own internal requirements, a Salesforce component might include the following in its manifest:

{
  "custom": {
    "salesforce.com": {
      "apiVersion": "53", /* Salesforce platform API version targeted by this component */
      "formFactor": "mobile", /* Component is designed primarily for mobile use */
      "capabilities": [ /* In which product environments is the component capable of being used? */
        "dashboard",
        "communities"
      ]
    }
  }
}

Something like this would minimize the impact on the schema design, give component creators a way to include component metadata in a single place, and increase the chance that a tool created by one group could be used by a different group without choking on unexpected custom data. This would also provide a means of trying out new ideas for schema fields before standardizing on them.

[steel]

1. We expect to see tools that look at jsDoc annotations (say) in component source files and use those to generate a manifest based on what they find

This is exactly what we are doing here: https://github.com/polleverywhere/custom-element-analyzer We register these tags and parse the js files using jsdoc-api and output the formatted json.

[thepassle]

Just curious, but why not just have a separate salesforce.json file for these custom properties? Tools could easily pick it up and combine it with the custom elements manifest. I’m not entirely convinced having a kitchen sink custom property would be worth it just for the fact that users only have to add metadata in a single place.

This would also provide a means of trying out new ideas for schema fields before standardizing on them.

This feels like things could become messy pretty quickly 😅 Tools would first have to implement them under the custom property, and if it does get standardized, it would have to be implemented in the actual schema in a different place, im not sure if that would be the most efficient way to go about trying out new fields.