#486 Unify instantiation mechanisms

[willosborne]

Make nodes, relationships, metadata and interfaces all use the same code for instantiation

Addresses #486

[rocketstack-matt]

Make nodes, relationships, metadata and interfaces all use the same code for instantiation

Addresses #486

Is #486 actually addressed in this PR? Interfaces seem to be generated exactly the same way, using the following pattern

{
  "$schema": "https://raw.githubusercontent.com/finos/architecture-as-code/main/calm/draft/2024-04/meta/core.json",
  "title": "Test CLI Pattern",
  "type": "object",
  "properties": {
    "nodes": {
      "type": "array",
      "minItems": 1,
      "prefixItems": [
        {
          "$ref": "https://raw.githubusercontent.com/finos/architecture-as-code/main/calm/draft/2024-04/meta/core.json#/defs/node",
          "type": "object",
          "properties": {
            "unique-id": {
              "const": "system-001"
            },
            "name": {
              "const": "Demo System"
            },
            "description": {
              "const": "Demo System to test generation"
            },
            "node-type": {
              "const": "system"
            },
            "interfaces": {
              "type": "array",
              "minItems": 1,
              "prefixItems": [
                {
                  "$ref": "https://raw.githubusercontent.com/finos/architecture-as-code/main/calm/draft/2024-04/meta/interface.json#/defs/rate-limit-interface",
                  "type": "object",
                  "properties": {
                    "unique-id": {
                      "const": "rate-limit-info"
                    }
                  }
                }
              ]
            }
          }
        }
      ]
    },
    "required": [
      "nodes"
    ]
  }
}

I get exactly the same instantiation whether generating with the 0.2.4 version of the CLI from npm or the locally built and installed version:

{
  "nodes": [
    {
      "unique-id": "system-001",
      "node-type": "system",
      "name": "Demo System",
      "description": "Demo System to test generation",
      "interfaces": [
        {
          "unique-id": "rate-limit-info",
          "key": "{{ REF_KEY }}",
          "time": -1,
          "time-unit": "{{ REF_TIME_UNIT }}",
          "calls": -1
        }
      ]
    }
  ],
  "relationships": [],
  "metadata": []
}

If the intent of this PR is purely refactor and not change the behaviour then seems correct.

We should probably also bump the patch version of the CLI in package.json and index.ts to 0.2.5 to ensure folks realise there was a change.

[willosborne]

That's interesting, I have not seen the same behaviour. Let me try to reproduce, maybe there's something I've missed

[willosborne]

Alright, so some considerable more diving has revealed my problem.
The schema directory is smart enough to recursively resolve $refs when it's pulling out a definition.
But once you go to actually generate that definition later on, it's already thrown away the info about which schema those definitions belong to.

i.e. a $ref: #/defs/abcd within interface.json is indistinguishable from one that references a local def at the bottom of the current pattern.

So what I'm working on now is a means to disambiguate the local references (i.e. without a schema ID, beginning with just a #) by turning them into absolute references including the full URI.

Note that just using file references is probably going to break this for now. e.g. interface.json#/defs/rate-limit-key from another file won't get fully disambiguated to https://calm.com/pattern/etc

This is a little more gnarly than I thought; I'm wondering if maybe I should introduce a secondary data structure to track where things came from when they get generated.

[willosborne]

Made some big improvements here. It now qualifies all relative references (at least, within the same file) with the full ID.
Also can do enums now too:

I also added a logging hint as to the potential values for an instantiated enum:

[Thels]

Potentially ignorable, but any reason why we aren't building tests to the most recent version on the schema?

[willosborne]

No particular reason. Would you mind if I got this larger PR merged before going back and making these changes? It keeps getting broken by other changes 😆