SDK and command interface

[whilefoo]

Related to ubiquity-os/ubiquity-os-kernel#186

[whilefoo]

@gentlementlegen can't request you for review

[gentlementlegen]

@whilefoo When I try to run this, I get the following error:
Manifest is invalid.

I am running the kernel from the related PR for LLM. Commands look like this in the manifest of this PR

  "commands": [
    {
      "name": "start",
      "ubiquity:example": "/start",
      "description": "Assign yourself and/or others to the issue/task.",
      "parameters": {
        "type": "object",
        "properties": {
          "teammates": {
            "description": "Users other than yourself to assign to the issue",
            "type": "array",
            "items": {
              "description": "Github username",
              "type": "string"
            }
          }
        }
      }
    },
    {
      "name": "stop",
      "ubiquity:example": "/stop",
      "description": "Unassign yourself from the issue/task.",
      "parameters": {
        "type": "object",
        "properties": {

        }
      }
    }
  ],

They are an array when they should be an object, why is that?

[whilefoo]

Did you link to the new SDK using bun link @ubiquity-os/plugin-sdk?
I'm thinking if manifest and other types should be inside the kernel and the SDK imports the kernel, it makes more sense to make kernel the source of truth so to say.

They are an array when they should be an object, why is that?

Honestly I thought it's easier as an array to just put these objects into OpenAI functions but later realized it's neither easier nor harder, I can change back to the object if you think it's better

[gentlementlegen]

@whilefoo The plus side of the object is that it prevents duplicate keys.

Yes I usually link with --watch so I don't have to think about it. We can get the code back to the kernel if you think that is beneficial, but as we discussed before we need to absolutely make sure there is no circular reference of any import otherwise that will break the compilation.

I had an awful time splitting the SDK itself, because of the following:

• if everything is compiled within index.d.ts then every lib is included which is useless and can lead to circular imports or incompatible packages
• splitting it with subpath is not possible except if using node16 option at least
• node16 is really bad because it forces silly things like adding .js at the end of the import paths, and breaks some libs
• there is the bundler option that mitigates that but doesn't solve everything
• the trick I found was to use the future imports, that leverage part of the node16 and upwards features while being compatible with the plain node as seen here

Smashed my head on the desk a whole day to fix this.

[whilefoo]

Yes I usually link with --watch so I don't have to think about it. We can get the code back to the kernel if you think that is beneficial, but as we discussed before we need to absolutely make sure there is no circular reference of any import otherwise that will break the compilation.

I assume you built the SDK?
What I had to do is first use bun link @ubiquity-os/plugin-sdk in the SDK and then also run bun link @ubiquity-os/plugin-sdk in the plugin. Make sure to use bun install even if the plugin is using yarn, because you have to use the same package manager

• the trick I found was to use the future imports, that leverage part of the node16 and upwards features while being compatible with the plain node as seen here

Ohh, that's why I couldn't import octokit subpath that I added, I didn't see that I also need to add typesVersion. I also tried to switching to different module resolutions but nothing worked

[gentlementlegen]

@whilefoo yes that's another reason why I switched to bun in the conversation rewards because it is easier to link with the same package manager. Usually using bun instead of yarn temporarily to install packages has not been a problem.

Yes if you don't add it node is incapable of resolving the path even if it is there and described in package.json, all will tell you to switch to node16 which then introduces too many problems.