Plugin API to add more applications to code-server

[nhooyr]

This PR introduces the commits that implement the plugin system we've discussed.

It is described in detail in ./typings/plugin.d.ts.

The overlay is not yet implemented but I'm working on it.

[wbobeirne]

Code overall looks good, but deviates from the agreed spec. We should probably catch up about the changes.

[nhooyr]

So addressed every comment + added /api/applications endpoint + plugins/apps now have a homepage field.

Should be good to merge now!

[nhooyr]

Example endpoint output (also in docs):

[
  {
    "name": "Test App",
    "version": "4.0.0",
    "iconPath": "/test-plugin/test-app/icon.svg",
    "path": "/test-plugin/test-app",
    "description": "This app does XYZ.",
    "homepageURL": "https://example.com",
    "plugin": {
      "name": "test-plugin",
      "version": "1.0.0",
      "modulePath": "/Users/nhooyr/src/cdr/code-server/test/test-plugin",
      "displayName": "Test Plugin",
      "description": "Plugin used in code-server tests.",
      "routerPath": "/test-plugin",
      "homepageURL": "https://example.com"
    }
  }
]

[wbobeirne]

Started creating a test plugin for this and ran into some quirks.

I also think this may be going too hard on the plugins === applications angle, but we can loosen that up later if something like an rsync plugin or other "headless" plugin became useful to consider.

[wbobeirne]

The ergonomics of this are kind of weird, any reason we don't just do a single export of an interface so that you can type your export? Right now you'd just have to "know" that you're fulfilling the expected exports, and we wouldn't be able to communicate breaking changes to the API via TS types, just through throwing.

[nhooyr]

Yea I agree it's weird. Is there any way to type a bunch of your top level exports?

If not, I'll just make the top level export a single plugin and then that'll be easy.

[wbobeirne]

There's not, to my knowledge.

[wbobeirne]

This annoyingly warns on every npm command, perhaps we should use a custom key?

warning code-server-example-plugin@0.0.1: The engine "code-server" appears to be invalid.

[nhooyr]

So this is how vscode does things as well. I'm leaning in favour of keeping it the same to keep with the idiom but also ok changing to our own key.

cc @code-asher

[wbobeirne]

Cool, no worries if it's already convention

[code-asher]

It does seem to be a convention in use, as mentioned VS Code does it this way and I could have sworn I've seen it elsewhere although the details escape me. Supposedly --ignore-engines can ignore it; I wonder if that's a valid setting for a .yarnrc or something.

[code-asher]

👍

[nhooyr]

I also think this may be going too hard on the plugins === applications angle, but we can loosen that up later if something like an rsync plugin or other "headless" plugin became useful to consider.

Agreed things can definitely easily change later. I'm not sure what would be useful to consider or how it'd work so I can't design for them. I do think that they should be able to easily work with just the init function, report zero applications and register zero routes. Perhaps we'd need another field to indicate they provide no applications/are headless so we can indicate that in the overlay.

[wbobeirne]

This makes it accessible on e.g. //test-plugin, not /test-plugin.

Suggested change

	r.use(`/${p.routerPath}`, p.router())
	r.use(p.routerPath, p.router())

[nhooyr]

Ah interesting, I figured express would normalize it.

[code-asher]

We could have just init that returns all the info and optionally a router and an applications func (or pass init something that lets you do something like api.registerRoute()) then if it doesn't have a router skip the use and if it doesn't have applications skip it when getting all the apps.

[nhooyr]

How about we just make the applications and router callback optional? I prefer that to putting things into init as it's not really something that will change per init, it's something the plugin either implements or doesn't.