feat: add transistor config schema file

[francinelucca]

Adds a schema file for transistor config with npm and jsx scope typings.

Note for @jdharvey-ibm I made some constraints here that I felt made sense like:

• require top-level "collect" and "projectId" keys
• require at least 1 scope to be defined
• require at least 1 property to be defined per scope
• require at least 1 attribute if allowedAtrributeNames is defined
• require at least 1 string value if allowedAttributeStringValues is define

Changelog

New

• Added transistor config schema file: src/schemas/transistor-config.schema.json
• Added dedicated per-scope schema files

Testing / reviewing

test out adding and removing keys from test.yml or creating your own file

TODO: remove test.yml file

[mattrosno]

I like how we are using a published package for the Carbon Platform schema to validate YAML config files. E.g.

# yaml-language-server: $schema=https://unpkg.com/@carbon-platform/schemas@v1/carbon-resources.schema.json
designKits:
  carbon-white-sketch:
    name: Sketch white theme

Do we want the schema to live in its own package?

Or, if we want to publish it as part of this package (e.g. @ibm/transistor-js), what would we need to do to expose the schema as part of the top level package so an instrumented code package could use unpkg to use a versioned schema file? E.g.:

# yaml-language-server: $schema=https://unpkg.com/@ibm/transistor-js@v1/transistor-config.schema.json
collect:
    npm:
        dependencies:

Said differently, how could we achieve this:

https://unpkg.com/@ibm/transistor-js@v1/transistor-config.schema.json

Instead of depending on the internal directory structure:

https://unpkg.com/@ibm/transistor-js@v1/src/schemas/transistor-config.schema.json?

[mattrosno]

With top-level collect and projectId keys, we're dependent on the YAML file names like transistor.yml to find and parse the config.

I'm wondering if we should nest everything inside a top-level transistor key, e.g.:

transistor:
  collect:
    npm:
      dependencies:
  projectId: "1234"

Would this enable potential future config and indexing consolidation? Let's say the future has one ibm.yml config to both instrument for metrics and index for website catalogs:

assets:
  accordion:
    name: Accordion
  aspect-ratio:
    name: Aspect ratio
libraries:
  carbon-react:
    name: Carbon React
    assets:
      $ref: '#/assets'
transistor:
  collect:
    npm:
      dependencies:
  projectId: "1234"

Or... if collect and projectId are unique and have no foreseen conflicts with Carbon Platform and InnerSource indexing... then we're good and we don't need the top level transistor key?

CC @jdharvey-ibm

[francinelucca]

Schema location/urls:

Schema will eventually live in it's own package for reusability's sake since other emitters will also depend on it. The schema will be served alongside emitters' published code. How emitters consume the schema from it's standalone repository could go to ways:
a) we publish the schema as it's own package to npm and the emitters consume it by installing it
b) the packages download the schema from it's repository location directly and bundle it into their build without going through npm

To make a decision between these two approaches we'll need to construct POCs and evaluate.

---

Top level transistor key and file dependency

we will not depend on a transistor.yml file. Instead, we will require packages to tell us via a command on the postinstall script (or whatever the entry point is in the language that is being used) to tell use where their configuration file lives.

we will not add a top level key at this point and can easily do so shall the time come in the future when this and other libraries and schemas are more mature.

---

We are going to split out scopes into individual scope files and pull them in into the broader schema file by reference

[francinelucca]

changed required properties for minProperties: 1 instead and moved scope schemas into their own files. ready for re-rev @jdharvey-ibm @mattrosno

[mattrosno]

Just some description prose cleanup.

[mattrosno]

Comments in Schema.ts LGTM.