Closed 0xTim closed 2 years ago
Here's a link to the existing community swift devcontainer, that uses a different plugin. GitHub codespaces provides a setup flow that lets people select from the list of languages in the linked Microsoft repo.
Personally I think it's reasonable to migrate the official devcontainer setup from the existing plugin to the SSWG plugin.
There is also some existing node setup in the existing swift devcontainer that could be trimmed out.
Example of swift package with a devcontainer on the existing devcontainer.
Not sure what the state of the world is in terms of the best lldb extension for VS Code but using the one mentioned in the linked article worked for me.
Using a Dockerfile from the swift:5.5.2
image with this devcontainer
config:
{
"name": "Test",
"build": { "dockerfile": "Dockerfile" },
"extensions": [
"sswg.swift-lang",
"vadimcn.vscode-lldb"
],
"settings": {
"lldb.adapterType": "bundled",
"lldb.executable": "/usr/bin/lldb"
}
}
This is all you need for a dev container
{
"name": "Swift 5.5",
"image": "swift:5.5",
"extensions": [
// vscode-lldb is automatically loaded as swift-lang is dependent on it
"sswg.swift-lang",
],
"settings": {
// this setting stops the swift extension trying to set the linux lldb path in your workspace
"lldb.library": "/usr/lib/liblldb.so"
}
}
The Microsoft provided swift devcontainer references the other swift extension and does bad things like install its own version of lldb. We should get this fixed.
We should provide documentation for how to set up a development environment in VSCode with the extension using VSCode Remote Development. May be related to #81
Here's an old article that should still mostly apply https://medium.com/@ianpartridge/swift-development-in-docker-using-visual-studio-code-remote-b84d035e70db