-
Notifications
You must be signed in to change notification settings - Fork 50
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
Support Server Manager being able to handle objectscript.conn.docker-compose
type connections
#1471
base: master
Are you sure you want to change the base?
Support Server Manager being able to handle objectscript.conn.docker-compose
type connections
#1471
Conversation
…-compose` type connections
parts.length === 2 && | ||
(config("intersystems.servers").has(parts[0].toLowerCase()) || | ||
vscode.workspace.workspaceFolders.find( | ||
(ws) => ws.uri.scheme === "file" && ws.name.toLowerCase() === parts[0].toLowerCase() |
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.
Is it possible that someone would want to do this for non-file
workspace folders?
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.
Maybe, but at this point I'm coding defensively to minimize the chance of unexpected side-effects from my changes.
|
||
// An async variant capable of resolving docker port number. | ||
// It is exported as one of our API functions but is also used internally. | ||
async function asyncServerForUri(uri: vscode.Uri): Promise<any> { |
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.
What does this mean for Language Server? Does it have to change to support these docker compose
connections?
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 don't think so. It will continue to ask the ObjectScript extension for the connection details (host, port, pathPrefix etc) as usual. This extension does the magic.
@@ -731,15 +780,20 @@ export async function activate(context: vscode.ExtensionContext): Promise<any> { | |||
vscode.workspace.workspaceFolders?.map((workspaceFolder) => { | |||
const uri = workspaceFolder.uri; | |||
const { configName } = connectionTarget(uri); | |||
const serverName = notIsfs(uri) ? config("conn", configName).server : configName; | |||
const conn = config("conn", configName); |
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.
Can we use the standard vscode.workspace.getConfiguration()
API instead of this old custom one? It would be nice to phase that out in the future.
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.
At this stage I'd prefer not to make unnecessary changes. The config(...)
function does a number of things that mean I don't think vscode.workspace.getConfiguration()
is a drop-in replacement.
This PR enables an incoming Server Manager enhancement to implement intersystems-community/intersystems-servermanager#187
The VSIX built from this PR should work OK with Server Manager VSIXes that don't contain the relevant change, and vice versa. However the new features will only become available when both extensions have been updated.