Is sunbeam on pause?

[b-per]

Hi!

I am a big fan of sunbeam and its integration with Raycast but I noticed that while being clause to v1 there are still some changes happening on the extension/command. I built a few extensions for me but I think that commands don't work yet in the latest version.

Would you like/need any help to get v1 out?

[pomdtr]

Hey! I'm working on a total overhaul of the extension api (look at the v1 branch).

It bring's a lot of improvements (support for multiple clients, http extension, command completions...)

Any help would be welcome!

[pomdtr]

Hey! I just pushed a new release that implement the v1 api.

Most of the documentation was outdated so I removed it, but you can take a look at the example to get a grasp of it.

I would love to get your feedback on it :)

[b-per]

Amazing! I will see if I can have a quick look this weekend or early next week.

[b-per]

Looking at it already now for a bit. For my understanding, would it be possible to get a tldr on what was changed from when there was an extension command a few versions ago (the one I was on before)?

From what I see for now:

• the JSON schema(s) was changed
• installing extensions/commands is no longer done via sunbeam ... but by adding sunbeam-xxx scripts in ~/local/bin

Is it correct? And are there other changes from the extension standpoint?

[pomdtr]

yeah i was not satisfied with the previous extension model: it was too complex, and using local scripts was a bit hard to edit (you needed to write your scripts, and then run sunbeam extension install ...). Windows support was also a bit convoluted.

Now it is much simpler, and in the future I will add support for a package manager in the style of krew. I love this idea of renaming a command just by renaming a file.

On the api level:

• The scripts must return a valid manifest when called with no args.
• When a command is run by the user, the command name / params are passed as script first argument, as a json payload (so you don't need to parse arguments in your language of choice).
  • if the command mode is view, the command must return a page
  • if the command mode is no-view, the command must return a "command" (I need to find a better nomenclature here)

It is a bit more complex than the previous one, but you get a lot of benefits:

• you get completions + help generation in the cli
• you can run extensions remotely (see sunbeam serve command, or this val: https://www.val.town/v/pomdtr.sunbeamValTown)

[noelzubin]

I love the using sunbeam. I was wondering if you ever considered having the mode be in the returned json instead having it manifest.commands

ie instead of having mode in manifest

"commands": [
    {
      "name": "list-entries",
      "title": "List Entries from Docset",
      "mode": "filter",
      "hidden": false,
      "params": [
        {
          "name": "slug",
          "type": "string", // can be "string", "number", "boolean"
          "title": "Docset Slug",
        }
      ]
    }
  ] 

What if the json returned could have the mode
say for filter:

{
  "mode": "filter",
  "items": [...]
}

This way the script could decide what the next view would be . Are there any obvious disadvantages to this approach ?
@pomdtr

[pomdtr]

The main disadvantage is that you loose the "root view" of sunbeam, and the automatic cli commands generation.

But I agree that the current api is cumbersome, so it might be worth it.