-
Notifications
You must be signed in to change notification settings - Fork 12.4k
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
Allows plugin to register commands #44291
Allows plugin to register commands #44291
Conversation
This PR doesn't have any linked issues. Please open an issue that references this PR. From there we can discuss and prioritise. |
@sheetalkamat this seems about right to me. Thoughts? |
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.
I would rather prefer if enablePlugins passes session (along with project which is already passed in) to the plugin rather than having these extra methods and we having to deal with the additions etc
b411c08
to
fad1c05
Compare
I'm not pretty sure what's different about these kind of projects. |
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.
Also add test for plugin where session is passed through and you call addProtocolHandler and test that functionality
Tests are in src/testRunner/unittests/tsserver/plugins.ts
@@ -783,10 +784,13 @@ namespace ts.server { | |||
/*@internal*/ | |||
private packageJsonFilesMap: ESMap<Path, FileWatcher> | undefined; | |||
|
|||
/*@internal*/ | |||
readonly session: Session<unknown> | undefined; |
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.
I think you should wire TMessage thing here and PluginCreateInfo too,
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.
I thought the unknown
is better:
If we add type parameter TMessage
into editorService
, We should also add the type parameter into Project
and etc. Too many changes.
And we are not really care about the type of message in editorService
. We just forward session into pluin.
And the handlers
or addProtocolHandler
does not have TMessage
too. Thay are raw string.
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.
If that’s the case we shouldn’t add it to project service options either
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.
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.
need to update tsserverlibrary.d.ts baseline but otherwise change looks good. Thank you for your patience and sorry for going back and forth on this one as it was little unclear if TypeParameter was needed or not until you made those changes.
Never mind. |
@Kingwl are you OK if I un-draft and merge this? |
Sure. Please feel free to merge. |
Just noticed this in the PR backlog. I'm going to merge it since it looks ready to go. |
#43449