[DO NOT MERGE] Prototype for SPI integration #809
Conversation
This change is a prototype for SPI integration. It provides two new
commands that leverage the new add package workflows within swiftpm
* Add package
* Browse Package Index...
Add package is fairly straight forward. It prompts the user for
both the package URL and the version, and adds the package to their
Package.swift (by calling swift package add...). An alternative here
would be to have the LSP do the equivalent refactoring operation.
Browse Package Index opens a webview to the SPI (note in this patch
it's using localhost) in an iframe. The intent is that the SPI can
detect that it is running through the vscode webview and provide
alternative UI for adding a package. This is accomplished through:
* A window event listener between the frame and the webview in which
messages that can be sent [1]
* Access to the vscode api from the webview that post a message
to run the command. This invokes the add package command detailed
above
[1] - SPI usage
- SPI would need to detect that it is running in the vscode context
and present alternative (or augmented UI). In the example given
it could use window.name to check and see if it is equal to
"vscode_iframe"
- When the user takes the action to add their package using this new
UI, SPI needs to send a message to its parent.
window.parent.postMessage(
{
action: 'addPackage',
url: url,
version: version
}, '*')
The add package related commands (add package, browse swift package index) would previously show an error if the user ran the command but had a swift toolchain that was older than 6.0. This adds a context key so that the command doesn't appear in this case.
Unfortunately it won't be functional until SPI has added support |
|
But @daveyc123 it didn't even show the SPI website. |
In the patch it's pointing to localhost so that it can be tested against a locally running SPI with the appropriate changes. |
| return; | ||
| } | ||
|
|
||
| const panel = vscode.window.createWebviewPanel( |
There was a problem hiding this comment.
Can we break out some of the web view stuff, into a general function that can be used by other systems. Currently when you right click on a package dependency and select View Repository it opens a web page in your default browser. Would be cool if we could do that inside VSCode instead in a similar manner to how this works.
| // The context key `swift.addPackageRefactoringAvailable` only works if the extension has been | ||
| // activated. As such, we also have to allow this command to run when no workspace is | ||
| // active. Show an error to the user if the command is unavailable. | ||
| if (!ctx.toolchain.swiftVersion.isGreaterThanOrEqual(new Version(6, 0, 0))) { |
There was a problem hiding this comment.
What's the point of having this command available when you have no package loaded?
This change is a prototype for SPI integration. It provides two new commands that leverage the new add package workflows within swiftpm
Add package is fairly straight forward. It prompts the user for both the package URL and the version, and adds the package to their Package.swift (by calling swift package add...). An alternative here would be to have the LSP do the equivalent refactoring operation.
Browse Package Index opens a webview to the SPI (note in this patch it's using localhost) in an iframe. The intent is that the SPI can detect that it is running through the vscode webview and provide alternative UI for adding a package. This is accomplished through:
[1] - SPI usage