-
Notifications
You must be signed in to change notification settings - Fork 6k
Plugin API to add more applications to code-server #2252
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
ec67639
to
9e5fa30
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code overall looks good, but deviates from the agreed spec. We should probably catch up about the changes.
90d46cb
to
24e46c3
Compare
So addressed every comment + added Should be good to merge now! |
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"
}
}
] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
test/test-plugin/src/index.ts
Outdated
export const displayName = "Test Plugin" | ||
export const routerPath = "/test-plugin" | ||
export const homepageURL = "https://example.com" | ||
export const description = "Plugin used in code-server tests." |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's not, to my knowledge.
"name": "test-plugin", | ||
"version": "1.0.0", | ||
"engines": { | ||
"code-server": "^3.6.0" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This annoyingly warns on every npm command, perhaps we should use a custom key?
warning [email protected]: The engine "code-server" appears to be invalid.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool, no worries if it's already convention
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
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 |
src/node/plugin.ts
Outdated
*/ | ||
public mount(r: express.Router): void { | ||
for (const [, p] of this.plugins) { | ||
r.use(`/${p.routerPath}`, p.router()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This makes it accessible on e.g. //test-plugin
, not /test-plugin
.
r.use(`/${p.routerPath}`, p.router()) | |
r.use(p.routerPath, p.router()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah interesting, I figured express would normalize it.
We could have just |
How about we just make the applications and router callback optional? I prefer that to putting things into |
ef7ce56
to
3f1750c
Compare
Will work on testing overlay next.
See my discussion with Will in the PR.
More clear.
Addresses Will's comments.
Next commit will address Will's comments about the typings being weird.
Makes typing much easier. Addresse's Will's last comment.
Unfortunately we can't use node-mocks-http to test a express.Router that has async routes. See eugef/node-mocks-http#225 router will just return undefined if the executing handler is async and so the test will have no way to wait for it to complete. Thus, we have to use supertest which starts an actual HTTP server in the background and uses a HTTP client to send requests.
3e82a47
to
6bc111f
Compare
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.