Open joshsedl opened 2 years ago
An attach to Container command will be added in the future! See here for when it's released: https://code.visualstudio.com/docs/remote/devcontainer-cli Source: https://github.com/microsoft/vscode-remote-release/issues/5278#issuecomment-992492106
As a workaround, we could run "ddev code" on drowl-init, wait until VSCode attached to the web server and then write our settings / extensions to the attached container settings.
Unfortunatly, as we use WSL2 these attached Container Settings are sitting inside the Windows Folder Structure: "C:/Username/AppData/Roaming/Code/User/globalStorage/ms-vscode-remote.remote-containers/nameConfigs-ddev-ddev-vscode-devcontainer-drupal9-template-web.json" (check via command "Remote-Containers: Open Container Configuration")
See https://code.visualstudio.com/docs/remote/attach-container#_attached-container-configuration-files for more information about the attached container configuration file.
NOTE, that we can not use da devcontainer.json, and link our web image Dockerfile as a starting point, as then VSCode will orchestrate our container and not ddev any more. Hence the web level ddev commands will not work anymore.
I think apart from ddev / docker / remote the correct way here is indeed to use the .vscode
folder and/or .code-workspace
file instead of other possible workarounds. That's also transparent!
See https://code.visualstudio.com/docs/editor/workspaces
For production copies I think this should not be used by default.
Idea: perhaps instead of having -dev
and -prod
with different receipts, we should have smaller flags like the "ddev xdebug on" which add or remove defined parts, like vscode configurations, dev modules etc.?
When setting up the project, these commands would then be called automatically, so they can also be split cleanly.
If you like the idea @joshsedl we should perhaps have a master plan issue for these prod / dev things and the idea could be elaborated there... I just wrote it down here, as I came up with this when thinking about vscode integration into production projects like Drupal dev modules etc... so it's not only Drupal specific.
Let's talk about this inside https://github.com/webksde/ddev-vscode-devcontainer-drupal-template/issues/124
There is now the Devcontainer CLI, but unfortunately I don't think, that is, what we are looking for. See: https://github.com/microsoft/vscode-remote-release/issues/5278#issuecomment-1785017392.
We now can install extensions through code --install-extension <extension>
, see https://code.visualstudio.com/docs/editor/command-line#_working-with-extensions I don't think they will go into the devcontainer.json, but might be a "better" workaround, then waiting for the extension popup / searching for @recommended in the shop.
Ah devcontainer up
might be actually it now! https://github.com/microsoft/vscode-remote-release/issues/5278#issuecomment-1785723387, this is way better then our current approach using some random hex values to attach VSCode, which currently also seems to make us run into issues, see #162.
Created a first MR draft (only code, not tested yet) here: https://github.com/webksde/ddev-vscode-devcontainer-drupal-template/pull/163
Nope, https://github.com/webksde/ddev-vscode-devcontainer-drupal-template/issues/74#issuecomment-1926481957 did not help... oh well, back to the drawing board.
I'll keep the issue branch open for future reference.
It is currently not possible to use a custom settings/extensions for the attached container, current workaround uses a workspace in the project directory with custom workspace settings/extensions, but inside a workspace it is only possible to recommend these extensions not force install them. Furthermore it seems like some workspace settings get overwritten by my "normal" VSCode settings which should not happen.
Everything documented here: https://github.com/microsoft/vscode-remote-release/issues/5944
and here: https://github.com/webksde/ddev-vscode-devcontainer-drupal9-template/issues/28